Ready Circuit 


Keystroke Functional Test (Part A) 

CONNECTION TABLE 


STIMULUS 

MEASUREMENT 



I/O MOD 

I/O MOD 

U4-4 

U4-5 

U1-4 

U4-6 



RESPONSE TABLE 


SIGNAL 

PART PIN 

I/O MOD PIN 

SIGNATURE 

READY 

U1-4 

4 

0015 

SRDY 

U4-6 

26 

0015 
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Figure 4-125: Ready Circuit Functional Test (Part A) 
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Keystroke Functional Test (Part B) 

CONNECTION TABLE 


STIMULUS 

MEASUREMENT 



POD 

I/O MOD 

TEST ACCESS SOCKET 

U4-6 

I/O MOD 

U4-11 



RESPONSE TABLE #1 


SIGNAL 

PART PIN 

I/O MOD PIN 

SIGNATURE 

ASYNC LEVEL 

SRDY 

U4-6 

26 

0 0 0 0 

10 



RESPONSE TABLE #2 


SIGNAL 

PART PIN 

I/O MOD PIN 

ASYNC LEVEL 

TRANS COUNT 

SRDY 

U4-6 

26 

0 1 

3 
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Figure 4-126: Ready Circuit Functional Test (Part B) 
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Keystroke Functional Test (Part C) 

CONNECTION TABLE 


STIMULUS 

MEASUREMENT 



I/O MOD 

I/O MOD 

U5-1 

U17-9 

U5-3 



RESPONSE TABLE 


SIGNAL 

PART PIN 

I/O MOD PIN 

SIGNATURE 

— 

U5-3 

3 

0 0 0 A 
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Figure 4-127: Ready Circuit Functional Test (Part C) 
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Keystroke Functional Test (Part D) 

CONNECTION TABLE 


STIMULUS 

MEASUREMENT CONTROL 

MEASUREMENT 




I/O MOD 

I/O MOD 

I/O MOD 

U17-9 

CLOCK U1-10 

START U4-11 

U17-11 



RESPONSE TABLE #1 


SIGNAL 

PART PIN 

I/O MOD PIN 

ASYNC LEVEL 

TRANS COUNT 

3WAITS 

U17-11 

17 

01 

1 


RESPONSE TABLE #2 


SIGNAL 

PART PIN 

I/O MOD PIN 

TRANS COUNT 

3WAITS 

U17-11 

17 

0 
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Figure 4-128: Ready Circuit Functional Test (Part D) 
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Programmed Functional Test 4 . 14 . 6 . 

The tstjeady program is the programmed functional test for the 
Ready Circuit functional block. This program checks the Ready 
circuit using the gfi test command. If the gfi test command fails, 
the abortjest program is executed and GFI troubleshooting 
begins. (See the Bus Buffer functional block for a discussion of 
the abortjest program). 

The gfi test command executes a number of stimulus programs. 
The ready_1, ready_2, ready_3, and readyjf stimulus programs 
overdrive nodes in order to break the feedback loop in the Ready 
circuit. These programs will ask the operator to use a second 
clip on a second component so that the circuit can be overdriven. 

program tst_ready 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 

! FUNCTIONAL TEST of the READY functional block. ! 

I This program tests the READY functional block of the Demo/Trainer. 1 
! The gfi test command and I/O module are used to perform the test. The I 
! ready test involves overdriving components to break the feedback loop ! 

! in the ready partition. Two I/O module clips are required; one for ! 

! measurement and one for stimulus (overdriving). ! 

! TEST PROGRAMS CALLED: 1 

! abort_test (ref-pin) If gfi has an accusation ! 

! display the accusation else ! 

! create a gfi hint for the ! 

! ref-pin and terminate the test! 

! program (GFI begins trouble- ! 

! shooting). ! 

it tiit t t tt t t t m tt j t t t tit m t t t j tt t t t tti? t t t t t t t t t t t t t t t t it t t t tt t tt t t t t t tt t 


if (gfi status M Ul-4") = "untested" then 
print "\nl\nlTESTING READY CIRCUIT" 

podsetup 'enable ~ready' "off" 
podsetup 'report forcing' "off" 

if (gfi status "Ul-4") = "untested" then gfi test "Ul-4" 
if (gfi status "Ul-4") = "bad" or (gfi status "Ul-2") = "bad" or 

(gfi status "Ul-3") - "bad" then 

abort__test ("Ul-4") 
else 

print "READY CIRCUIT PASSES" 
end if 
end if 
end program 
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Stimulus Programs and Responses 4.14.7. 

Figure 4-129 is the stimulus program planning diagram for the 
Ready Circuit functional block. The ready_l, ready_2, 
ready_3, and ready_4 stimulus programs use one clip for 
measurement and a second clip to overdrive the Ready circuit in 
order to break the feedback loop in this circuit, ready_5 and 
ready6 provide stimulus to measure the operation of the I/O 
ready generator, U17. These two stimulus programs count how 
many 8 Mhz clocks occur during the wait state generated by 
U17. 

The steps to break the Ready feedback loop to diagnose a fault 
are shown below: 

1. Overdrive inputs U4-4 and U4-5. Then measure 
outputs U4-6 and Ul-4. The 82284 chip (Ul) 
synchronizes the Ready output (U4-6) to the 
microprocessor read/write cycles. This requires the 
ready_1 stimulus program to output the level, allow 
enough time for the signal to get synchronized, then 
check the level at the output Ul-4. 

2. Finish breaking the Ready signal feedback loop by 
overdriving inputs U4-12 and U4-13, then measure 
the outputs U4-11, U5-3, and U4-6. In order to 
measure U5-3 and U4-6, the other inputs U5-1 and 
U4-5 must be held high so the signals will flow 
through the AND gates. The ready_4 stimulus 
program performs this step. 

3. Hold the node with output source U4-11 high. This 
allows signals from U6 to flow through U5-3 to U4- 
6. At the same time, holding U4-11 high causes 
output U17-11 to stabilize at a high state, allowing 
signals from U56 to ripple through U5-6 to U4-6. 
Now use the pod to exercise the Ready Circuit inputs 
that are driven by the Address Decode functional 
block. The ready_2 stimulus program performs this 
sequence for all components that can be forced to use 
zero wait states. It does this by disabling U17 (all 
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components except RAM and Video RAM). Since 
the pod has turned -READY ENABLE OFF, the pod 
generates a sync pulse with zero wait states. 
Because the RAM and Video RAM return wait states, 
taking signature measurements on RAM and Video 
RAM will turn out to be unstable. To solve this 
problem, ready 2 accesses all components except 
RAM and Video RAM. Then the ready_3 stimulus 
program performs a similar operation, but exercises 
only RAM and Video RAM. ready_3 responses are 
characterized by asynchronous level history and 
transition counts to allow the RAM and Video RAM 
wait state signals to be measured. 

4. Measure the I/O component wait state generator, 
U17. The Clear input at U17-9 is toggled low. At 
the same time a measurement using external Clock 
(and Start) is made. The External Clock line is 
connected to the 8 MHz clock CLK and the Start line 
is connected to the node which includes U17-9. A 
Stop Count is set and transition counts and level 
history are measured. The ready_6 stimulus 
program uses a Stop Count of four clocks and the 
response is expected to be low level history and zero 
transitions, indicating that the wait state output was 
low for at least four clocks. The ready_5 stimulus 
program uses a Stop Count of six clocks. In this 
case, a response of high and low level history is 
expected, and a transition count of 1 is expected. 
These results indicate that the wait state finished 
within six clock cycles. 


Advice for Making GFI Work in the Presence of Ready Faults 

When a Ready fault exists, a forcing-line fault condition will be 
generated. However, the pod must ignore the Ready 
forcing-line fault condition so that the stimulus program will 
execute completely. Otherwise, a fault condition would be 
generated and GFI would terminate. To turn this report off, a 
SETUP REPORT FORCING -READY OFF command can be 
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performed. When this is done, the pod will continue to respond 
to the Ready signal, but will not generate a fault message. If the 
Ready signal is stuck high, the pod will cause the 9100A/9105A 
to generate a pod timeout fault condition. To cure this, a SETUP 
ENABLE ~READY OFF command is performed. At this point, 
GFI will work properly and Ready problems can be isolated to 
the failing component or node. 

More generally, GFI works best if every stimulus program turns 
all reporting conditions off. In addition, those stimulus 
programs that create activity in the kernel area, may need to turn 
off Enable Ready. All Demo/Trainer UUT stimulus programs 
related to the address bus, data bus, control signals, address 
decoding, interrupts, and ready circuitry turn the Ready Enable 
off at the beginning of the stimulus program and the turn Ready 
Enable back on at the end of the program. 

One more note: the 80286 microprocessor uses a separate bus 
controller that has no feedback lines to the microprocessor. 
When the pod disables the Ready input and performs zero wait 
state operations regardless of the Ready input, the bus controller 
can get out of synchronization from the pod and may get 
confused. When this happens, an enabled line timeout fault 
condition is generated. The solution is to provide a handler for 
that fault condition in each stimulus program that enables and 
disables Ready. The handler for the fault condition should call a 
program which performs a recovery procedure. The recovery 
procedure depends on the UUT. Usually, forcing the Ready 
line active or performing a Reset will recover synchronization. 
Or, by disabling Ready and then performing a read or write in 
memory space followed by enabling Ready may recover 
synchronization of the 80286 pod and the bus controller. Most 
other microprocessors do not have this problem. 
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Stimulus Program Planning 


PROGRAM: READY_1 


PROGRAM: READY_4 

OVERDRIVES U4-6 TO CHECK THE SYNCHRONIZED 


BREAKS THE READY FEEDBACK LOOP BY 

READY OUTPUT 


OVERDRIVING THE NODE AT U4-11 

MEASUREMENT AT: 


MEASUREMENT AT: 

U1-4 


U4-11 

U4-6 


U5-3 



PROGRAM: READY_2 


PROGRAM: READY_5 

OVERDRIVES THE NODE AT U4-11 AND ALSO 


OVERDRIVES THE INPUT TO THE I/O WAIT STATE 

EXERCISES THE READY RETURN LINES (EXCEPT 


GENERATOR AND CHECKS THAT THE OUTPUT 

VRAM AND VRAMRDY) 


U17-11 TRANSITIONS FROM LOW TO HIGH WITHIN 7 



CLOCKS OF THE INPUT U17-9 

MEASUREMENT AT: 





MEASUREMENT AT: 

U4-6.8 



U5-3.6 


U17-11 

U6-8 



U56-8 




PROGRAM: READY_3 


OVERDRIVES THE NODE AT U4-11 AND EXERCISES 
THE READY RETURN LINES VRAM AND VRAMRDY 


MEASUREMENT AT: 

U4-6 

U5-3 

U6-8 


PROGRAM: READY_6 


OVERDRIVES THE INTUT TO THE I/O WAIT STATE 
GENERATOR AND CHECKS THAT THE OUTPUT 
U17-11 TRANSITIONS FROM HIGH TO LOW WITHIN 4 
CLOCKS AFTER U17-9 GOES HIGH 


MEASUREMENT AT: 

U17-11 
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Figure 4-129: Ready Circuit Stimulus Program Planning 
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program ready_l 

!!!!!!!!!!!!!!!!!!I!!!!!!!!!!!!!!!! I!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 1! 11 !!! 
! STIMULUS PROGRAM overdrives U4 in ready circuit. 

! Characterizes U4-6 and Ul-4. 

t 

! Stimulus programs and response files are used by GFI to backtrace 
! from a failing node. The stimulus program must create repeatable UUT 
! activity and the response file contains the known-good responses for 
! the outputs in the UUT that are stimulated by the stimulus program. 

f 

! This stimulus program is one of the programs which creates activity 
! in the kernel area of the UUT. These programs create activity with 
! or without the ready circuit working properly. Because of this, all 
! the stimulus programs in the kernel area must disable the READY input 
! to the pod, then perform the stimulus, then re-enable the READY input 
! to the pod. The 80286 microprocessor has a separate bus controller; 

I for this reason, disabling ready and performing stimulus can get the 
! bus controller out of synchronization with the pod. Two fault 
! handlers trap pod timeout conditions that indicate the bus controller 
! is out of synchronization. The recover() program is executed to 
! resynchronize the bus controller and the pod. 

! TEST PROGRAMS CALLED: 

! recover () 


GRAPHICS PROGRAMS CALLED: 
(none) 

Global Variables Modified: 
recover times 


Local Variables Modified: 
measure_dev 
stimulus_dev 

t t rit m iiiiiiit ? *ii m' t! » rij!!M j j 11!!!| !!! t;! ! t !!! j j t ! t j t! i ! ! it ! m M t j 


i j ! m tij m t jI;tiiiiit!!j t!it!!]tti11 m m! 11!j j!r r111!!t tt j j! it t ! ! ! it i j t j 

! Main Declarations 

t t I 1 I ! t I I I t J t t J I t t I I I I ! I I 1 I t I M M J J t t t t M t I I t t I I J I t I I t T Jt J t M M M I t t I t J » 


The 80286 microprocessor has a! 
bus controller that is totally! 
separate from the pod. In ! 
some cases the pod can get out! 
of sync with the bus control- ! 
ler. The recover program ! 
resynchronizes the pod and the! 
bus controller. ! 


Reset to Zero 


Measurement device 
Stimulus device (overdrives) 


declare global numeric recover_times 


(continued on the next page) 

Figure 4-130: Stimulus Program (ready_1) 
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I I I I I I I 1 1 l 1 1 I 1 I I I I I I I I I I I t t t I I I t t t I I t M t 1 

! FAULT HANDLERS: 

! ! t t t t t t i i t t t t t t t t t i r t t ti i t t i i t t t t t i i t t i i 

miiniiiiiimttii 

II ! 1 1 1 I t 1 1 1 1 1 II 1 ! 1 t ! 

I 1 1 II 1 t I 1 I I 1 

? 1 II II 1 It It 1 

handle pod_timeout_enabled_line 
recover () 
end handle 

handle pod_timeout_recovered 
recover () 
end handle 

handle pod timout no elk 
end handle 

I I I I It I I I ! M It 1 I I I It M I I 1 1 1 It I I I I I I t I I I I I 

I 1 I II I 1 1 1 1 It I I I tl M I 

mm min 

! Main part of STIMULUS PROGRAM 

i i i i i i t t t t i i t r i i i t 111 t t t t t t t t r i i i i t i i i 11 t 

I II 1 f 1 1 I 1 I t I 1 1 I I I 1 1 I 

i 

1 1 1 1 it i t i r i i 



recover_times « 0 

! Let GFX determine measurement device 

if {gfi control) = "yes” then 
measure__dev = gfi device 
measure_ref = gfi ref 
else 

print "Enter reference name of part to measure:" 
print " (Chose Ul, U4, 014 or U15)" 
measure_ref = "" \ input measure_ref 
if measure^ref <> "U14" then 

meas ure_.de v = clip ref measure_ref 
else 

probe ref "U14-63" \ measure_dev = "/probe" 
end if 
end if 

! Determine stimulus device 

if measure_ref = "U4" then 
stimulus_dev = measure_dev 
else 

print "\07\1B[2J\1B[201\lB[3;lf USING \lB[7mSECOND\lB[Om CLIP." 

stimulus_dev = clip ref "U4" 
print "\lB[20h" 
end if 

print "Stimulus Program READY_1" 


(continued on the next page) 


Figure 4-130: Stimulus Program (ready_1) - continued 
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! Setup measurement device. 


podsetup 'enable -ready' "off" 
podsetup 'standby function off' 
podsetup 'report power' "off" 
podsetup 'report forcing' "off" 
podsetup 'report intr' "off" 
podsetup 'report address' "off" 
podsetup 'report data' "off" 
podsetup 'report control' "off" 
reset device measure_dev 
reset device stimulus_dev 
sync device measure_dev, mode "int" 

! Perform Stimulus 


arm device measure_dev 

writepin device "U4", pin 4, level "1", 

writepin device "U4", pin 5, level "1", 

strobedock device measure_dev 
writepin device "U4", pin 4, level "0", 

writepin device "U4", pin 5, level "1", 

strobeclock device measure_dev 
writepin device "U4", pin 4, level "1", 

writepin device "U4", pin 5, level "1", 

strobeclock device measure__dev 
writepin device "U4", pin 4, level "1", 

writepin device "U4", pin 5, level "0", 

strobeclock device measure_dev 
writepin device M U4", pin 4, level "1", 

writepin device "U4", pin 5, level "1", 

strobeclock device measure_dev 
readout device measure dev 


mode "latch" 
mode "latch" 

mode "latch" 
mode "latch" 

mode "latch" 
mode "latch" 

mode "latch" 
mode "latch" 

mode "latch" 
mode "latch" 


clearoutputs device stimulus_dev 
podsetup 'standby function on' 
podsetup 'enable -ready' "on" 


end program 


Figure 4-130: Stimulus Program (ready_1) - continued 
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STIMULUS PROGRAM NAME: READY_1 

DESCRIPTION: SIZE: 


Node 

Learned 


Signal Src 

With 

SIG 

U4-6 

I/O MODULE 

0015 

Ul-4 

PROBE 

0015 

Ul-4 

I/O MODULE 

0015 


- Response Data - 

Async Clk Counter 
LVL LVL Mode Counter Range 

1 0 TRANS 

1 0 TRANS 

1 0 TRANS 


Figure 4-131: Response File (ready_1) 


94 BYTES 

Priority 

Pin 
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program ready_2 

!!!!!! I!!!!!!!!!!!!!!! I!!!!!!!!!!!!!!!!!!!!!!!!!I !!!!!!!!!!!!!!!!!!!!!! ! 
I STIMULUS PROGRAM overdrives U4 in ready circuit. 

! Characterizes U4-6 and Ul-4. 

! Stimulus programs and response files are used by GFI to backtrace 
! from a failing node. The stimulus program must create repeatable UUT 
! activity and the response file contains the known-good responses for 
i the outputs in the UUT that are stimulated by the stimulus program. 

i 

! This stimulus program is one of the programs which creates activity 
! in the kernel area of the UUT. These programs create activity with 
! or without the ready circuit working properly. Because of this, all 
! the stimulus programs in the kernel area must disable the READY input 
! to the pod, then perform the stimulus, then re-enable the READY input 
! to the pod. The 80286 microprocessor has a separate bus controller; 

! for this reason, disabling ready and performing stimulus can get the 
! bus controller out of synchronization with the pod. Two fault 
! handlers trap pod timeout conditions that indicate the bus controller 
! is out of synchronization. The recover() program is executed to 
! resynchronize the bus controller and the pod. 

I 

1 TEST PROGRAMS CALLED: 

! recover () 


GRAPHICS PROGRAMS CALLED: 
(none) 

Global Variables Modified: 
recover times 


Local Variables Modified: 
measure_dev 
stimulus_dev 

tt i t t t t t it t t MMM M j 11 [MM!! m j j j! m MMM1 i j j t i j j j mm!!! m i MM]!! i 


m mm!!!!!!!!!! 11 j $ t m i M i i! t t mm!!!!! t ] t $ t m m j 11 j j t j mi t m i t t 11 j j! m 
! Main Declarations 

t t t t t t tit t tt11tii' 11 '''' 1 't 1 [j t!!!!!!!!!!!!!!!!!!!!!! ! I!!!!!!!!!!!!!!!! ! 


The 80286 microprocessor has a 
bus controller that is totally 
separate from the pod. In 
some cases the pod can get out 
of sync with the bus control¬ 
ler. The recover program 
resynchronizes the pod and the 
bus controller. 


Reset to Zero 


Measurement device 
Stimulus device (overdrives) 


declare global numeric recover__times 


(continued on the next page) 


Figure 4-132: Stimulus Program (ready_2) 
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It t M t t M t t t t t t t ! 1 I 1 t 1 t t t t t t t t t t t t 1 t t 1 t t t t t t 1 t t t t t 1 1 t t t t t 1 t I t t I t It t t f t M t 

j 

FAULT HANDLERS: 

t 1 t I I I t I t t t t 1 t t M I 

M t t t 

M t t t t t t t t I t t t t t M t M M 1 t 1 

tlffttttffffflftlttftff 


handle pod_timeout_enabled_line 
recover () 
end handle 

handle pod_timeout_recovered 
recover () 
end handle 

handle pod_timout_no_clk 
end handle 

!!!!I!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! I!!!!!!!! I !!!!!!!!!!!! 
! Main part of STIMULUS PROGRAM 

t it m i !!!!!!!!!!!!!!!!!!! M !!!!!!! !!!!!!!!!!!!!!! M !! !!!!!!!!!!!!!!!!!! ! 


recover_times = 0 

! Let GFI determine measurement device 

if (gfi control) = M yes" then 
measure_dev = gfi device 
measure_ref = gfi ref 
else 

print "Enter reference name of part to measure:" 
print » (Chose Ul, U4, U5, U6, U56 or U17)" 
measure_ref = "" \ input measure_ref 
measure_dev « clip ref measure_ref 
end if 

! Determine stimulus device 
if measure_ref = "Ul" then 

print "\07\1B[2J\1B[201\lB[3;lf USING \!B[7mSECOND\lB[0m CLIP." 

stimulusjdev = clip ref "U4" 
print "\lB[20h" 
else 

stimulusjdev = measure_dev 
end if 

print "Stimulus Program READY_2" 

! Setup measurement device. 

podsetup 'enable ~ready' "off" 

podsetup 'report power' "off" 

podsetup 'report forcing' "off" 

podsetup 'report intr' "off" 

podsetup 'report address' "off" 

podsetup 'report data' "off" 

podsetup 'report control' "off" 

io_byte = getspace space "i/o", size "byte" 

mem_word = getspace space "memory", size "word" 


(continued on the next page) 


Figure 4-132: Stimulus Program (ready_2) - continued 
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reset device measure_dev 

reset device stimulus_dev 

sync device measure_dev, mode "pod" 

sync device "/pod", mode "data" 

old_cal = getoffset device measure_dev 

setoffset device measure_dev, offset (1000000 - 56) 

if measure_ref = "U5 H then 

writepin device "U5", pin 2, level "1", mode "latch” 
writepin device "U5", pin 4, level "1", mode "latch" 
else if measure_ref - "U4" or measure__ref - "Ul" then 
writepin device "U4", pin 11, level "1", mode "latch" 
end if 

! Stimulate ICs and capture response. 


arm device measure_dev 
setspace (mem_word) 
read addr $30000 
read addr $40000 
read addr $50000 
read addr $E0000 
read addr $F0000 
setspace (io_byte) 
read addr 0 
read addr $2000 
read addr $4000 
readout device measure dev 


! Start response capture. 

! IPOLL 
! SPARE1 
! SPARE2 
! ROMO 
I ROM1 

! VIDSLT 
! I/OSLT 
I PPISLT 

! End response capture. 

device stimulus dev 


if stimulus_dev <> "/probe" then clearoutputs 
setoffset device measure_dev, offset old_cal 
podsetup ‘enable ~ready' "on" 


end program 


Figure 4-132: Stimulus Program (ready_2) - continued 
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STIMULUS PROGRAM NAME: 
DESCRIPTION: 


READY 2 


SIZE: 


Node 

Learned 


Signal Src 

With 

SIG 

U4-6 

I/O MODULE 

0000 

a 

*6. 

1 

CD 

PROBE 

007E 

U4-8 

I/O MODULE 

007E 

U5-3 

I/O MODULE 

0086 

U5-6 

I/O MODULE 

0078 

U56-8 

PROBE 

0086 

U56-8 

I/O MODULE 

0086 

U6-8 

I/O MODULE 

0078 


- Response Data - 

Async Clk Counter 
LVL LVL Mode Counter Range 

1 0 TRANS 

1 0 TRANS 

1 0 TRANS 

1 0 TRANS 

1 0 TRANS 

1 0 TRANS 

1 0 TRANS 

1 0 TRANS 




Figure 4-133: Response File (ready_2) 


143 BYTES 

Priority 

Pin 
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program ready_3 


!!!I I!!I I I!I I!!I!!!!!I!!!J !!!!!!! I Ms!!! !J !!!!!!!!! MI!!!!!!!!!!!!!!! ] 
STIMULUS PROGRAM toggles ready circuit inputs which generate 
wait states. 


Stimulus programs and response files are used by GFI to backtrace 
from a failing node. The stimulus program must create repeatable UUT 
activity and the response file contains the known-good responses for 
the outputs in the UUT that are stimulated by the stimulus program. 

This stimulus program is one of the programs which creates activity 
in the kernel area of the UUT. These programs create activity with 
or without the ready circuit working properly. Because of this, all 
the stimulus programs in the kernel area must disable the READY input 
to the pod, then perform the stimulus, then re-enable the READY input 
to the pod. The 80286 microprocessor has a separate bus controller; 
for this reason, disabling ready and performing stimulus can get the 
bus controller out of synchronization with the pod. Two fault 
handlers trap pod timeout conditions that indicate the bus controller 
is out of synchronization. The recover{) program is executed to 
resynchronize the bus controller and the pod. 


TEST PROGRAMS CALLED: 
recover () 


GRAPHICS PROGRAMS CALLED: 

(none) 

Global Variables Modified: 
recover_times 

Local Variables Modified: 
measure_dev 
stimulus_dev 

I II M M I I I I I I t I I I I I I t t M M I I I I J I T 


The 80286 microprocessor has a 
bus controller that is totally 
separate from the pod. In 
some cases the pod can get out 
of sync with the bus control¬ 
ler. The recover program 
resynchronizes the pod and the 
bus controller. 


Reset to Zero 


Measurement device 
Stimulus device (overdrives) 
i i r t t t t i t i t l f i t t t r t i t i t t t t t t : 


!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 
! Main Declarations 

t J I i j J M t J M M J t M J I M J J t J J t J J J ' ' I M M M t I I J I I 1 I I I t M I 1 I I I t t ! I I I t I I I I I 


declare global numeric recover_times 


(continued on the next page) 


Figure 4-134: Stimulus Program (ready_3) 
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!!!!!!!!!!!!!!!!!!!!!!!!!!I!!!!!!I! !!!!!!!!!!! I !!!!!! I !!!!!!!! ! I! ! ! ! ! ! ! 
FAULT HANDLERS: 

t ! t t t ! t t t t t t t t t t !M m t f!!!!!!!!!I!!!!!!!!!!!!!!!!!!! I !!!!!!!!! I!!!!!!! ! 


handle pod_tiraeout_enabled_line 
recover () 
end handle 

handle pod_timeout_recovered 
recover () 
end handle 

handle pod_timout_no_clk 
end handle 


t n t 2 t Mi n !!!!!!!!!!!!1!!!!!!!!!!!!!!!!!!! !! !!!!!!!!!!!!! !!!!!!!!!!!! ! 

Main part of STIMULUS PROGRAM 

it t tit t tit t t t t t tti j i11ti!t t 111Mi i ! t 11 ji t i t t t i i t t t t i i i f t ! ! i t i t j 11t t t t t t 


recover_times = 0 

! Let GFI determine measurement device 

if (gfi control) = "yes" then 
measure_dev = gfi device 
measure_ref = gfi ref 
else 

print "Enter reference name of part to measure:" 
print " (Chose Ul, U4, U5 or U6)" 
measure_ref = "" \ input measure_ref 
measure_dev = clip ref measure_ref 
end if 

! Determine stimulus device 
if measure_ref = "Ul" then 

print "\07\1B[2J\1B[201\lB[3;lf USING \!B[7mSECOND\lB[0m CLIP." 

stimulus_dev = clip ref "U4" 
print "\lB[20h" 
else 

stimulus_dev = measure_dev 
end if 

print "Stimulus Program READY_3" 


(continued on the next page) 


Figure 4-134: Stimulus Program (ready_3) - continued 
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! Setup measurement device. 

podsetup 'enable -ready' "off" 

podsetup 'standby function off' 

podsetup 'report power' "off" 

podsetup 'report forcing' "off" 

podsetup 'report intr' "off" 

podsetup 'report address' "off" 

podsetup 'report data' "off" 

podsetup 'report control' "off" 

io_byte » getspace space "i/o", size "byte" 

mem_word = getspace space "memory", size "word" 

reset device measure_dev 

reset device stimulus_dev 

sync device measure_dev, mode "pod" 

sync device "/pod", mode "data" 

old_cal = getoffset device measure_dev 

setoffset device measure_dev, offset (1000000 - 56) 


if measure ref = "U5" then 


writepin device "U5" 

, pin 

2, 

level "1", 

mode 

"latch" 

writepin device "U5" 

, pin 

4, 

level "1", 

mode 

"latch" 

else if measure ref = "U4" or measure ref = 

"Ul" 

then 

writepin device "U4" 

, pin 

11/ 

level "1", 

mode 

"latch" 


end if 

! Stimulate ICs and capture response. 

arm device measure_dev ! Start response capture, 

setspace (mem_word) 
read addr 0 ! RAM0 

read addr $10000 ! RAMI 

write addr $20000, data 0 ! VRAM (write only) 

readout device measure_dev ! End response capture. 

clearoutputs device stimulus_dev 
setoffset device measure__dev, offset old_cal 
podsetup 'standby function on' 
podsetup 'enable -ready' "on" 

end program 


Figure 4-134: Stimulus Program (ready_3) - continued 
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STIMULUS PROGRAM NAME: READY 3 


DESCRIPTION: 



SIZE: 

112 BYTES 

Node 

Learned 

Async Clk Counter 


Priority 

Signal Src 

With 

SIG LVL 

LVL Mode 

Counter Range 

Pin 

U4-6 

I/O MODULE 

1 0 

TRANS 

3 


U5-3 

I/O MODULE 

1 0 

TRANS 

3 


U6-8 

I/O MODULE 

1 0 

TRANS 

3 




Figure 4-135: Response File (ready_3) 
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program ready_4 

!!III!!!!!!!!!!! I!!!!!!!!! I! M !!!! 11!!!!! I!!!!!!! I!!!!!!!!!!!!! I!!!!!!! ! 
! STIMULUS PROGRAM overdrives U4 in ready circuit. 

! Characterizes U4-6 and Ul-4. 

I 

I Stimulus programs and response files are used by GFI to backtrace 
! from a failing node. The stimulus program must create repeatable UUT 
! activity and the response file contains the known-good responses for 
I the outputs in the UUT that are stimulated by the stimulus program. 

! This stimulus program is one of the programs which creates activity 
I in the kernel area of the UUT. These programs create activity with 
! or without the ready circuit working properly. Because of this, all 
! the stimulus programs in the kernel area must disable the READY input 
! to the pod, then perform the stimulus, then re-enable the READY input 
! to the pod. The 80286 microprocessor has a separate bus controller; 

! for this reason, disabling ready and performing stimulus can get the 
! bus controller out of synchronization with the pod. Two fault 
! handlers trap pod timeout conditions that indicate the bus controller 
! is out of synchronization. The recover () program is executed to 
! resynchronize the bus controller and the pod. 

I 

! TEST PROGRAMS CALLED: 

! recover () 


GRAPHICS PROGRAMS CALLED: 

(none) 

Global Variables Modified: 
recover_times 

Local Variables Modified: 
measure_dev 
stimulusjdev 

I I 11 111 I 1 I i r I I t 1 11 11 111 I I T I 111111 I I I 1111 111! 11 111111 1111111 I I I 1 111 I ! t I I 


The 80286 microprocessor has a 
bus controller that is totally 
separate from the pod. In 
some cases the pod can get out 
of sync with the bus control¬ 
ler. The recover program 
resynchroni 2 es the pod and the 
bus controller. 


Reset to Zero 


Measurement device 
Stimulus device (overdrives) 


!!!!!!!!!!!!!!!!!!!!!!11!!!!!!!!!!!!!!!I!!!!!!!! I!!!!!! I!!!!!!!!! I ! II!!! 
! Main Declarations 

t t tititiiiiit tit 11111 11 tit t t i ji11 t t 11»i it t t 111 f m t t M t 11 m t i i 111111 it it t 


declare global numeric recover_times 


(continued on the next page) 

Figure 4-136: Stimulus Program (ready_4) 
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!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 
! FAULT HANDLERS: 

!!!! I! I! 111!!!!!!!!!!!!! I M !!!!!!! 11!!!!!!! M !!!! I!!!!!!!!!!!!!!! 11 J! t t i 

handle pod_timeout_enabled_line 
recover () 
end handle 

handle pod_timeout_recovered 
recover () 
end handle 

handle pod_timout_no_clk 
end handle 

!! I ] 3 !!!!!!!!!!!!!!!!!!!! I !! !! I!!!!!!!!!!! i! !!!!! I! !!!!! i !!!!!!!!!!!!!! ! 

! Main part of STIMULUS PROGRAM 

!!!!! J! J 3! 31!!!!!!!!!!!! II!!!!!!!!! II»!!!!!!!! n tt J J m m i t !M t t m m t m j j 
recover_times = 0 

3 Let GFI determine measurement device 

if (gfi control) = "yes” then 
measure_dev = gfi device 
measure_ref = gfi ref 
else 

print "Enter reference name of part to measure:" 
print " (Chose U4, U5 or U17)" 
measure_ref = "" \ input measure_ref 
measure_dev = clip ref measure_ref 
end if 


! Determine stimulus device 

if measure__ref = "U4" then 

print "\07\1B[2J\1B[201\1B[3;If 
stimulus_dev = clip ref "U45" 
else if measure_ref = "U5" then 
print "\07\1B[2J\1B[201\1B[3; If 
stimulus_dev = clip ref "U17" 
else if measure_ref = "U17" then 
print M \07\lB[2J\lB(201\lB[3;lf 
stimulus_dev = clip ref "U4" 
end if 

print "\lB[20h" 

print "Stimulus Program READY_4" 


USING \lB[7mSECOND\lB[Om CLIP." 

USING \1B[7mSEC0ND\lB[Om CLIP." 
USING \1B[7mSEC0ND\lB[Om CLIP." 


(continued on the next page) 


Figure 4-136: Stimulus Program (ready_4) - continued 
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! Setup measurement device. 


podsetup 'enable ~ready' "off" 
podsetup 'report power' "off" 
podsetup 'report forcing' "off" 
podsetup 'report intr' "off" 
podsetup 'report address' "off" 
podsetup 'report data' "off" 
podsetup 'report control' "off" 
reset device measure_dev 
reset device stimulus_dev 
sync device measure_dev, mode " 
sync device stimulus_dev, mode 


int" 

"int" 


if measure_ref = "U4" then 

storepatt device "U4", pin 12, 
storepatt device "U4", pin 13, 
storepatt device "U45", pin 6, 
storepatt device "U45", pin 3, 
else if measure_ref = "U5" then 
storepatt device "U5", pin 1, 
storepatt device "U17", pin 9, 
else if measure_ref = "U17" then 
storepatt device "U4", pin 12, 
storepatt device "U4", pin 13, 
end if 


patt "10111" 
patt "11101" 
patt "00000" 
patt "00000" 

patt "11111" 
patt "10101" 

patt "10111" 
patt "11101" 


l Provide stimulus to UUT using I/O module to overdrive. 

arm device measure_dev 

if measure_ref = "U4" then 

writepatt device "U45,U4", mode "pulse" 
else if measure_ref = "U5" then 

writepatt device "U17,U5", mode "pulse" 
else if measure_ref = "U17" then 

writepatt device "U4", mode "pulse" 
end if 

readout device measure_dev 

podsetup 'enable ~ready' "on" 
end program 


Figure 4-136: Stimulus Program (ready_4) - continued 
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STIMULUS PROGRAM NAME: READY_4 

DESCRIPTION: SIZE: 


Response Data 


Node Learned Async Clk Counter 


Signal Src 

With 

SIG 

LVL 

LVL Mode 

Counter Range 

U4-11 

I/O MODULE 

0015 

1 0 

TRANS 


U5-3 

I/O MODULE 

00 0A 

1 0 

TRANS 



Figure 4-137: Response File (ready_4) 


78 BYTES 

Priority 

Pin 
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program ready_5 

!!!!!!!!!!!!!! M !!!!!! t j it !!!!!] m I mm! t ! tt !!!! m m M t !!! tt t t t !!! j m ! M 

! STIMULUS PROGRAM characterizes the ready circuit. 

t 

! Stimulus programs and response files are used by GFI to backtrace 
! from a failing node. The stimulus program must create repeatable UUT 
! activity and the response file contains the known-good responses for 
! the outputs in the UUT that are stimulated by the stimulus program. 

i 

! This stimulus program is one of the programs which creates activity 
! in the kernel area of the UUT. These programs create activity with 
I or without the ready circuit working properly. Because of this, all 
! the stimulus programs in the kernel area must disable the READY input 
! to the pod, then perform the stimulus, then re-enable the READY input 
! to the pod. The 80286 microprocessor has a separate bus controller; 

! for this reason, disabling ready and performing stimulus can get the 
! bus controller out of synchronization with the pod. Two fault 
! handlers trap pod timeout conditions that indicate the bus controller 
! is out of synchronization. The recover() program is executed to 
! resynchronize the bus controller and the pod. 

t 

! TEST PROGRAMS CALLED: 

! recover () The 80286 microprocessor has a 

! bus controller that is totally 

t separate from the pod. In 

t some cases the pod can get out 

! of sync with the bus control- 

! ler. The recover program 

! resynchronizes the pod and the 

! bus controller. 

i 

! check_meas (device, start, stop, clock, enable) 

l Checks to see if the measure- 

! ment is complete using the 

! TL/1 checkstatus command. If 

! the measurement times out then 

i redisplay connect locations. 
j 

! GRAPHICS PROGRAMS CALLED: 

! (none) 

I 

! Local Variables Modified: 

j done returned from check_meas() 

t 

! Global Variables Modified: 

! recover_times Reset to Zero 

j 

! Local Variables Modified: 

] measure_dev Measurement device 

! stimulus dev Stimulus device (overdrives) 

ii ! i m it t tt j j T M!!!!! t !!!!{j] j j!!!!!!! j |} !!!!!! S J j | m ! t!!!!!!!!!!!! j I!! t 


(continued on the next page) 


Figure 4-138: Stimulus Program (ready_5) 
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! Main Declarations 

t t t t t It I t t t t ! 11 t t t M t t t t t t 1 t 1 ff t t t t t 1 1 11 M t t 111 t t t 1 t 1 

declare global numeric recover times 
declare numeric done = 0 

11 M t t M t t t t t t t t 1 1 I J t 1 f 11 111 111 t t 11 It t t 11 n 11! t 111111 

i i t 111 i i i i i i t t 1111 i t 

iiiittitMiiiiiiiiit 

!!!!!!!!!!!! 1 ! I ! I I 1 t 

! FAULT HANDLERS: 

t t t t t t t 1 1 It 1 1 1 M 1 t t t t t t t t t t t 1 t t t t t It t t It 1 t t t t t t 1 t t t t t 

i it t t 1 i i i i it i t t i t i i i 

handle pod_timeout_enabled_line 
recover () 
end handle 

handle pod_timeout recovered 
recover() 


end handle 

1 t i 1 M M I M M l I t 1 t t t t t t t t t t t 1 11 M t t t t t 111 t t t t t 1 t t I t t t 

1 M 1 1 1 1 1 1 1 1 1 M 1 t 1 1 1 1 

! Main part of STIMULUS PROGRAM 

1 1 1 1 1 1 1 1 1 1 1 M 1 1 1 M 1 1 1 1 1 t 1 1 1 1 t 1 1 1 1 1 1 t t M 11 1 1 1 t t 1 1 1 1 1 1 1 

I 

i i i t t t t t t t t t t t i t i i i i 


recoverjtimes = 0 

! Let GFI determine the measurement device. 


if (gfi control) = "yes" then 
measure_dev = gfi device 
measure_ref = gfi ref 
else 

print "Enter reference name of part to measure:" 
print " (Chose U5 or U17}" 
measure_ref - "" \ input measure_ref 
measure_dev - clip ref measure_ref 
end if 

print "Stimulus Program READY_5" 

I Set addressing mode and setup measurement device. 


podsetup 'enable ~ready' "off" 

podsetup 'standby function off' 

podsetup 'report power' "off" 

podsetup 'report forcing' "off" 

podsetup 'report intr' "off" 

podsetup 'report address' "off" 

podsetup 'report data' "off" 

podsetup 'report control' "off" 

setspace( getspace{ "i/o", "byte" )) 

reset device measure_dev 

sync device measure_dev, mode "ext" 

enable device measure_dev, mode "high" 

edge device measure_dev, start "+", stop "count" 

stopcount device measure_dev, count 7 


clock 


(continued on the next page) 

Figure 4-138: Stimulus Program (ready_5) - continued 
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! Prompt user to connect external 


lines. 



if measure_ref = "U17" then 
connect device measure_dev, 
else 

connect device measure_dev, 
end if 


start ,, U4-11 I 
start "U17-9 1 


clock "Ul-10 1 
clock "Ul-10 1 


common "gnd" 
common "gnd" 


! External lines determine measurement. 

loop until done = 1 

arm device measure_dev 
read addr 0 

done = check_meas(measure_dev,"U4-11", "*", "Ul-10", "*") 
readout device measure_dev 
end loop 

clearoutputs device measurejdev 
podsetup ‘standby function on* 
podsetup ’enable ~ready' "on" 
end program 



Figure 4-138: Stimulus Program (ready._5) - continued 
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STIMULUS PROGRAM NAME: READY_5 

DESCRIPTION: SIZE: 69 BYTES 




--Response Data- 


Node 

Learned 

Async Clk Counter 

Priority 

Signal Src 

With 

SIG LVL LVL Mode Counter Range 

Pin 

U17-11 

I/O MODULE 

1 0 TRANS 1 



Figure 4-139: Response File (ready__5) 
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program ready_6 

t i i t ! | t t ! | ! 11 j j 11 m t i i i i i t I i 11! it it i it ! m ! it ! t m j t ti i t r t j ] it t i t t t ;! j j 11 t 
! STIMULUS PROGRAM to wiggle all address lines from the uP. 

! Stimulus programs and response files are used by GFI to backtrace 
! from a failing node. The stimulus program must create repeatable UUT 
! activity and the response file contains the known-good responses for 
! the outputs in the UUT that are stimulated by the stimulus program. 

! This stimulus program is one of the programs which creates activity 
! in the kernel area of the UUT. These programs create activity with 
! or without the ready circuit working properly. Because of this, all 
! the stimulus programs in the kernel area must disable the READY input 
! to the pod, then perform the stimulus, then re-enable the READY input 
i to the pod. The 80286 microprocessor has a separate bus controller; 

! for this reason, disabling ready and performing stimulus can get the 
I bus controller out of synchronization with the pod. Two fault 
! handlers trap pod timeout conditions that indicate the bus controller 
! is out of synchronization. The recover() program is executed to 
! resynchronize the bus controller and the pod. 

! TEST PROGRAMS CALLED: 

! recover () The 80286 microprocessor has a 

! bus controller that is totally 

! separate from the pod. In 

! some cases the pod can get out 

! of sync with the bus control- 

l ler. The recover program 

! resynchronizes the pod and the 

! bus controller. 

! GRAPHICS PROGRAMS CALLED: 

! (none) 

! Global Variables Modified: 

! recover_times Reset to Zero 

! Local Variables Modified: 

! measure_dev Measurement device 

! stimulus_dev Stimulus device (overdrives) 

! ! j!iti!titijiit jiiij jiiiiijij m it j j it t jit j j j j it i j m t j t m i i i i it i i i i 111 11 


(continued on the next page) 


Figure 4-140: Stimulus Program (ready_6) 
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I I I I I I I I I I I I I I I ! t ! i I i i i i i i i i i i i i i i i i i i i r i i i i i i i i i t t j i t 

! Main Declarations 

II 111111 1111111 111111 11111111 r 1111 11111 it 1111 it it 11 it t 

I I I I I I I 1 M I I I I t t t t t 

I 1 t t 1 t t M t 1 1 I 1 t t t t I 

declare global numeric recover times 


declare numeric done = 0 

t t t t t t t t t t t t t t t t t t t t t t I t t ! ! I I t M t t t t t t t I t t t t t t 1 11 t t t 11 

r 1 I 1 1 t t t t t t t t t I t i i i 

! FAULT HANDLERS: 

It t t M t t t t M t t t ! t » » l f t r I M It M t t t M 1 tt M t t M I It M ! » t It 

I t f if ! t 1 t M I t t I t t t M 

handle pod_timeout_enabled_line 
recover() 
end handle 

handle pod_timeout_recovered 
recover {) 


end handle 

t t t t M t M t t t t t 1 t 1 I t t t t t t t t 1 t t t t 1 I I t I 1 t t t t I I t t t t t t t r ! t t 

! ! t ! 1 t M t t t t t t t t t t t 

! Main part of STIMULUS PROGRAM 

1 1 t T t t t t t t t M t t t t t t t t t M t t t t t 1 t t t t t t t t t t t t t t t t t t t t t t t t 

t 

t t I J I t t t I t t I I t t t t t t 



recover_times - 0 

t Let GFI determine the measurement device. 


if (gfi control) = "yes" then 
measure_dev = gfi device 
measure_ref = gfi ref 
else 

print "Enter reference name of part to measure:" 
print " (Chose U5 or U17)" 
measure_ref = "" \ input measure_ref 
measure_dev = clip ref measure_ref 
end if 

print "Stimulus Program READY_6" 

! Set addressing mode and setup measurement device. 


podsetup 'enable ~ready' "off" 

podsetup 'standby function off 

podsetup 'report power' "off" 

podsetup 'report forcing' "off" 

podsetup 'report intr' "off" 

podsetup 'report address' "off" 

podsetup 'report data' "off" 

podsetup 'report control' "off" 

setspace( getspace( "i/o", "byte" )) 

reset device measure_dev 

sync device measure_jdev, mode "ext" 

enable device measure_dev, mode "high" 

edge device measure_dev, start stop "count", 

stopcount device measure_dev, count 4 


clock 


(continued on the next page) 


Figure 4-140: Stimulus Program (ready_6) - continued 
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! Prompt user to connect external lines, 
if measure_ref « "U17" then 

connect device measure_dev, start "U4-11", clock "Ul-10", common "gnd" 
else 

connect device measure_dev, start "U17-9", clock M U1-10 H , common "and 1 * 
end if 

1 External lines determine measurement. 

loop until done = 1 

am device measure_dev 
read addr 0 

done = check_meas (measure_dev, "U4-ll ,, / "Ul-10", 

readout device measure_dev 
end loop 

clearoutputs device measure_dev 
podsetup 'standby function on' 
podsetup 'enable -ready' "on" 

end program 


Figure 4-140: Stimulus Program (ready_6) - continued 









Ready Circuit 


STIMULUS PROGRAM NAME: READY_6 

DESCRIPTION: SIZE: 70 BYTES 




- Response Data - 


Node 

Learned 

Async Clk Counter 

Priority 

Signal Src 

With 

SIG LVL LVL Mode Counter Range 

Pin 

U17-11 

I/O MODULE 

10 0 TRANS 0 



Figure 4-141: Response File (ready_6) 
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Summary of Complete Solution for 

Ready Circuit 4 . 14 . 8 . 

The entire set of programs and files needed to test and GFI 
troubleshoot the Ready Circuit functional block is shown below. 
The format below is similar to a 9100A/9105A UUT directory 
(you could consider the functional block to be a small UUT), but 
in addition shows the use of each program and the location in 
this manual for each file. 

UUT DIRECTORY 
(Complete File Set for Ready Circuit) 


Programs (PROGRAM): 


TST READY 

Functional Test 

Section 4.14.5 

READY 1 

Stimulus Program 

Figure 4-130 

READY 2 

Stimulus Program 

Figure 4-132 

READY 3 

Stimulus Program 

Figure 4-134 

READY 4 

Stimulus Program 

Figure 4-136 

READY 5 

Stimulus Program 

Figure 4-138 

READY 6 

Stimulus Program 

Figure 4-140 

Stimulus Program Responses (RESPONSE): 


READY 1 


Figure 4-131 

READY 2 


Figure 4-133 

READY 3 


Figure 4-135 

READY 4 


Figure 4-137 

READY 5 


Figure 4-139 

READY 6 


Figure 4-141 

Node List (NODE): 

NODELIST 

Text Files (TEXT): 


Appendix B 


Reference Designator List (REF): 

REFLIST Appendix A 

Compiled Database (DATABASE): 

GFIDATA Compiled by the 9100A 


4-378 










Other Functional Blocks and Circuits 


OTHER FUNCTIONAL BLOCKS AND CIRCUITS 4.15. 

The 9100A/9105A provides the capability to handle a number of 
special circuits or situations. Among these are watchdog timers 
forcing lines, feedback loops, and in-circuit component testing. 


Watchdog Timers 4.15.1. 

Watchdog timers usually interfere with testing and 
troubleshooting. If your UUT has a watchdog timer, your test 
procedure or program must disable it before performing tests. 

Many watchdog timers initiate a master reset when they detect 
incorrect activity. Others may use a high-priority interrupt line 
to reset the system. 

Whenever possible, physically disable the watchdog timer with a 
jumper or switch provided for that purpose. If the watchdog 
timer cannot be disabled at the UUT, the 9100A/9105A may be 
able to ignore it with the SETUP POD REPORT FORCING 
SIGNAL ACTIVE OFF keypad command, or disable it with a 
command like SETUP POD ENABLE READY ON/OFF. Be 
very careful, however, when doing this. Read the precautions 
about these commands in Section 4.15.2, "Forcing Lines." 


Forcing Lines 4.15.2. 

In some situations, forcing lines must be disabled (disconnected 
from the pod microprocessor) during a test. You can do this 
with the SETUP POD ENABLE READY ON/OFF keypad 
command ("READY" is a pod-dependent choice; some pods 
may call this line by a different name). 

Exercise care whenever you disable a forcing line. Write or read 
commands to circuits that generate wait states through a Ready 
line may become unpredictable after the Ready line is disabled at 
the pod. 


4-379 











Other Functional Blocks and Circuits 


In addition to disabling forcing lines, you can also ignore them. 
The SETUP POD REPORT FORCING SIGNAL ACTIVE OFF 
keypad command will prevent the reporting of forcing lines. In 
this mode, the pod behaves normally but forcing conditions are 
not reported by the pod to the 9100A/9105A. 

Exercise care with this mode also. The pod's hardware 
performance is not affected and the pod will continue reacting to 
the forcing line. If the UUT generates a permanent wait state 
using a forcing line, the pod will halt and the system will display 
a timeout message. Other fault-indicating signals on your UUT 
will also be ignored if the forcing line is disabled. Be sure that 
your UUT hardware is not affected by the same forcing line. 


Breaking Feedback Loops 4.15.3. 

Microprocessor-based systems often have several feedback 
loops. The microprocessor and the components tied to the data 
and address buses form a large feedback loop. Most of the 
loops in the system will be broken when the microprocessor is 
replaced by the pod, because the pod can selectively ignore or 
report conditions of status and forcing lines. However, there 
may be additional loops which are not broken by the pod. 

Figure 4-125 shows a feedback loop in the Ready functional 
block of the Demo/Trainer UUT. The READY output (Ul-4) is 
fed back as an input at U4-12. 

To test a functional block that contains a feedback loop, drive all 
of its inputs, including the inputs connected to outputs that form 
the feedback loop, and measure the outputs. Use the I/O module 
to overdrive inputs while measuring signature, level, and count 
at the outputs. 


Visual and Acoustic Interfaces 4.15.4. 

Some circuits, such as LEDs and beepers, have both electrical 
characteristics and visual or acoustic characteristics . In general, 
stimulus programs should ignore the visual or acoustic 
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characteristics and measure only the electrical characteristics . 
The functional tests should prompt the test operator to verify the 
visual or acoustical characteristics. 

If the functional test fails, use the gfi test command. If gfi test 
fails, start GFI troubleshooting. If the functional test fails and 
gfi test passes, the part is bad, since the part operates incorrectly 
but the electrical signals at the part are good. 

In the case of the Parallel I/O functional block on the 
Demo/Trainer UUT, the functional test includes a prompt to the 
operator to verify the correct display on the LEDs. If the LEDs 
fail, the Parallel I/O functional test should perform a gfi test, 
which will run the stimulus programs and check the electrical 
properties. If gfi test passes (when the Parallel I/O functional 
test failed), it means that the electrical characteristics are good 
but the display is bad. The LEDs are bad and the operator 
should be prompted to replace them. If the gfi test fails, GFI 
troubleshooting can begin at the pin where the gfi test failed. 


In-Circuit Component Tests 4.15.5. 

If you wish, you can write TL/1 programs to test individual 
components rather than using the GFI to do so. These in-circuit 
component tests use a sequence of ones and zeroes defined with 
the TL/1 storepatt command and executed by the TL/1 writepatt 
command to overdrive the inputs of the component to be tested 
while measuring the signatures or level histories of its outputs. 
A test operator runs these tests by using the EXEC key to run 
the required program. 
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Other Functional Blocks and Circuits 
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Section 5 

UUT Go/No-Go 
Functional Tests 


PROGRAMMED GO/NO-GO FUNCTIONAL 

TESTING 5.1. 

The UUT go/no-go test is the third of four modular levels in 
programming the 9100A, as shown in Figure 5-1. In this third 
level, the go/no-go test determines whether the UUT is good 
(passes) or bad (fails). The go/no-go test combines built-in 
functional test commands with functional tests designed by the 
programmer. 

The go/no-go test is simple because it builds on the tests of 
functional blocks. It determines only whether the entire UUT is 
good or bad. It does not determine which functional block is 
causing a failure. 


CREATING A PROGRAMMED GO/NO-GO 

FUNCTIONAL TEST 5.2. 

Suppose a UUT has 14 functional blocks and a functional test is 
defined for each of them. One way to create a go/no-go test is to 
perform all 14 functional tests. Some blocks, however, can be 
tested indirectly by testing other blocks. For example, the bus 
buffer is assumed to be good if the ROM, RAM, and other 
blocks pass their tests. Therefore, a second way to create the 
go/no-go test is to perform functional tests only on functional 
blocks which cannot be tested indirectly by testing other blocks. 
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Figure 5-1: UUT Go/No-Go Functional Testing (Level 3) 
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Figure 5-2 shows the steps used to reach a go/no-go status 
decision. Care must be taken to ensure that your go/no-go test 
really does test the UUT for all possible faults. 

Figure 5-3 shows the structure of a go/no-go functional test for 
the Demo/Trainer UUT. For this UUT, only six functional 
blocks need to be tested for the go/no-go functional test of the 
UUT: Microprocessor Bus, RAM, ROM, Parallel I/O, Serial 
I/O, and Video. The microprocessor bus test is run first because 
it is built-in, fast, and provides excellent diagnostic information. 
A failure on the microprocessor bus will cause most other 
circuits to fail, so it is most efficient to check this functional 
block first. 

In the Demo/Trainer UUT, the following functional blocks are 
tested indirectly by the go/no-go test: 

Clock and Reset 
Ready Circuit 
Interrupt Circuit 
Bus Buffer 

Dynamic RAM Timing 
Address Decode 
Video Control 
Video RAM 

Figure 5-4 is a listing of the go/no-go functional test program for 
the Demo/Trainer UUT. It calls the functional test for each of 
the functional blocks which must be tested directly for the UUT 
go/no-go functional test to be complete. The remaining 
functional blocks are tested indirectly; if they fail, one of the six 
blocks that is tested by the go/no-go test will fail also. 


EVALUATING TEST EFFECTIVENESS 5.3. 

The purpose of the go/no-go test is to determine whether the 
UUT is good or bad. Two measures are frequently used to 
evaluate how well a go/no-go functional test performs: node 
activity and fault coverage. Node activity is important because 
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Figure 5-2: Go/No-Go Test Sequence 
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program go_nogo 


I I ! I ! I ! I ! ! ! I I I I I I ! I I I !!!!! I !!!!!!! II I!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! 
The Go/No-Go program is the highest level of the functional testing 
and fault handlers. The purpose of the Go/No-Go test is to determine 
whether the UUT is good or bad. This program executes six programs 
which test the six major functional blocks (Microprocessor Bus, ROM, 
RAM, Parallel I/O, Serial I/O, and Video functional blocks). 

By testing the six major functional blocks, the remaining 
functional blocks are indirectly tested. 

TEST PROGRAMS CALLED: 

test_bus () Test the microprocessor bus, 

buffered bus, and address 
select logic. 


test_rom {) 


Test the ROM functional block 
of the Demo/Trainer UUT. 


test_ram () 


Test the RAM functional block 
of the Demo/Trainer UUT. 


test_pia () 


Test the PARALLEL I/O 
functional block of the 
Demo/Trainer UUT. 


test_rs232 () 


test_video () 
miiMimiimmmt 


Test the SERIAL I/O 
functional block and the 
Interrupt Circuit functional 
block of the Demo/Trainer UUT. 

Test the VIDEO circuit of the 
Demo/Trainer UUT. 

tttttfttitiiii 


!! m ! m !!!!!!!!! i !!!!!!!!! m m i i i 
SETUP AND SYSTEM INITIALIZATION ! 


podsetup 'report power' "on" ! Turn on reporting functions except 

podsetup 'report intr' "off" ! interrupt which is tested in the 

podsetup 'report address' "on" I SERIAL I/O test (test__rs232). 

podsetup 'report control' "on" 
podsetup 'report data' "on" 
podsetup 'report forcing' "on" 

!!!!I!!!!!i!J11!!!!I!!!!!!!!!!!!! 11 !!!!!!!! M !!!!!!!! I!!!!!!!!! I !!! ! 

! This is the go/no-go test which runs the major functional tests. ! 

t j t tt j t t t t j t j m itiitt j j t t tt t j|r M j t j t; |;; j m i i m ' m r i ' ' ' ' ' t r 111 t t ' i i 


gfi clear ! CLEAR ALL GFI RECOMMENDATIONS 

connect clear "yes" ! Clear all connect information. 

execute test_bus{) 
execute test_rom{) 
execute test_ram() 
execute test_pia() 
execute test_rs232() 
execute test_video() 
end program 

Figure 5-4: Go/No-Go Test for Demo/Trainer UUT 


5-6 














each node on the UUT must be exercised for a thorough 
functional test. 

However, activity on each node is not a sufficient evaluation of 
test effectiveness. In addition, you need to evaluate how well 
your test detects faults in the UUT. This is done by injecting 
faults (such as stuck lows, stuck highs, intermittent highs, or 
intermittent lows) at each node in the UUT while running your 
functional test to see if the test fails. The 9100A/9105A probe 
(used as a source) provides a convenient tool for this purpose. 

Fault coverage is the percentage of faults that will be detected by 
the functional test software. It is often measured as the ratio of 
the number of nodes where injected faults can be detected by a 
test to the total number of nodes in the UUT. This ratio is 
usually expressed in percent. If the fault coverage is not high, 
you can analyze the pattern of faults that are not detected to 
determine additions to your test program to increase the fault 
coverage. 


EXECUTING UUT SELF-TESTS 5.4. 

Self-test routines contained in UUT memory can be executed 
from the 9100A/9105A by pressing the RUN UUT key at the 
operator's keypad and entering the UUT’s starting address of 
the routine. These self-test routines can also be run from TL/1 
programs by using the runuut command. Self-test routines 
typically save their test results in UUT RAM. The 
9100A/9105A can later read the appropriate RAM addresses to 
get these results. 

An I/O module can generate one hardware breakpoint (system 
interrupt) upon detection of any user-defined combination of 
logic-highs and logic-lows on selected I/O module lines. This 
feature may be invoked at the operator's keypad (SET I/O MOD 
COMPARE WORD command), or through program execution. 
Once set up for a breakpoint, the I/O module continuously 
monitors the specified lines while other functions (such as RUN 
UUT) are performed. When the breakpoint event occurs, RUN 
UUT execution halts. A breakpoint message will interrupt any 
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current system activity. If a program is being executed, it may 
redirect the breakpoint message through a fault condition 
handler, as described in Section 6 of this manual. 

A complete functional test for a UUT might begin with the BUS, 
RAM, and ROM tests, followed by execution of UUT self-test 
routines. By using RUN UUT breakpoints to detect addresses, 
data, and other UUT logic levels, the program can integrate the 
UUT's self-tests with 9100A/9105A functional tests. 

Some pods can also generate UUT breakpoints without using 
the I/O module. For these pods, breakpoint-related softkeys 
appear when the RUN UUT key is pressed. Consult your pod 
manual for these pod-specific breakpoint capabilities, if any. 


EXECUTING DOWNLOADED MACHINE CODE 5.5. 

After part of the UUT RAM has been tested and found to be 
good, machine code can be downloaded to the tested RAM and 
executed. The machine code may be downloaded using a series 
of WRITE commands or the WRITE BLOCK command, which 
downloads an entire Motorola-format user file. 

After the code is downloaded, you can execute it with the RUN 
UUT command, specifying the code's starting address. 
Although most testing can be done efficiently through the TL/1 
test language, downloading machine code is useful when the 
code for a test already exists, when the testing must be done at 
machine-code speeds, or when a feature not supported by the 
pod must be used as part of the test. 

The pod's microprocessor bus cycles are actually done at full 
UUT speed. The 9100A/9105A, however, is often slower than 
the UUT. For example, when the system performs a looping 
READ, each bus cycle is at full UUT speed but individual read 
operations are not done one immediately after the other. 
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Section 6 

Identifying a Faulty 
Functional Block 


After the go/no-go test determines that a UUT is faulty, the next 
step is to identify the failing functional block. Doing so before 
starting to troubleshoot will greatly improve troubleshooting 
efficiency because troubleshooting can begin closer to the failure 
and will take less time to reach the failing node. In addition, 
fault detection will be more accurate because the diagnostic test 
can check for special types of faults, such as bus contention, 
before troubleshooting begins. 

Programs that identify faulty functional blocks are called 
diagnostic programs. Diagnostic programs, which are a subset 
of troubleshooting procedures, build on the UUT go/no-go test, 
functional tests of blocks, and stimulus programs. They are the 
last of the four modular levels in programming the 9100A, as 
shown in Figure 6-1. In this fourth programming level, fault 
condition handlers and gfi hint commands are added to the UUT 
go/no-go test to create a diagnostic program that traps faults and 
initiates tests of functional blocks that may be responsible for the 
fault, thereby isolating the block that is causing the UUT to fail. 
In addition, a failing output of the faulty block is identified as a 
starting point for backtracing toward the fault that causes the 
block to fail. At that point, GFI troubleshooting (the GFI key 
on the operator's keypad) can be used to backtrace to the bad 
node or component. 
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Level 1 


• Stimulus Programs for Nodes 

• Learned Node Responses 
from Known-Good UUT 

• Node List and Reference 
Designator List (Both Optional) 



Figure 6-1: Diagnostic Programs (Level 4) 
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STRATEGY OF DIAGNOSTIC PROGRAMS 


6 . 1 . 


The first step in developing a diagnostic strategy is to draw a 
diagram showing the major functional blocks used in the go/no- 
go functional test. Next, show all other functional blocks that 
provide input to these major functional blocks. Figure 6-2 
shows such a diagram for the Demo/Trainer UUT. The figure 
shows six sets of functional blocks, one for each major 
functional block tested by the go/no-go functional test. The 
blocks on the left provide input to the blocks on the right, and 
the blocks tested by the go/no-go functional test are on the right 
side of each set. 

The task of the diagnostic program is to select a failing 
functional block for troubleshooting and to generate an 
appropriate starting point (or points) where GFI can begin 
automated troubleshooting. When a major functional block 
fails, you know that one or more outputs of the block are bad. 
But it doesn't necessarily mean that the block itself is bad; bad 
inputs to the major functional block may be causing the block to 
fail. How do you continue from there to isolate the failing block 
and select an efficient starting point for GFI? 

One diagnostic strategy is to test blocks that provide input to the 
failing major block. Isolating the block causing a failure 
involves tracing from the right-hand side toward the left, testing 
each block in the path until one is found with good inputs and 
bad outputs. This strategy works best when the string of blocks 
leading up to a major block is short. Such is the case for most 
of the sets of blocks in Figure 6-2. 

A second diagnostic strategy, helpful when you have a longer 
string of blocks leading up to a failing major block, is to divide 
the blocks in half and begin testing a block halfway between the 
first block in the string and the major block at the end. If the 
middle block passes, keep dividing the failing string of blocks in 
half and testing a middle block. If the middle block fails, test the 
blocks to the left starting at the middle block. This second 
strategy would be appropriate for the Video set of blocks in 
Figure 6-2. 
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Bus Buffer 


MICROPROCESSOR BUS 



(continued on the next page) 


Figure 6-2: Inputs to Functional Blocks 


6 -' 



















VIDEO 



Figure 6-2: Inputs to Functional Blocks- continued 
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Another strategy, used when a fault is likely to be near a failing 
output pin of the failing major block, is to begin GFI backdating 
directly from the failing output pin, without checking the inputs 
to the major functional block. 

Diagnostic programs can speed up troubleshooting by starting 
GFI closer to the actual problem. On the other hand, isolating 
the failure to a very small area may require more time than is 
saved in reduced troubleshooting time. There is a balance 
between isolating the failure to a very small area and doing no 
isolation of the failing circuit. Decisions on when to start GFI 
and when to isolate the failure to a smaller area depend on your 
UUT and the relative cost of additional programming effort 
compared to the resulting savings in troubleshooting time. 


IMPLEMENTING THE STRATEGY FOR 

DIAGNOSTIC PROGRAMS 6.2. 

Figure 6-3 shows a typical process to implement a diagnostic 
program strategy. The diagnostic program executes a functional 
test for each major functional block. If a fault condition is 
generated during the test, the major functional block is possibly 
faulty. To verify this suspicion, the inputs to the functional 
block are checked. If the inputs are all good, then the major 
functional block is indeed faulty. Flowever, if one of the inputs 
to a major functional block is not good, the fault probably lies in 
the functional blocks which provide input to the major functional 
block. In this case, the input functional blocks become the 
suspect blocks and their inputs are checked. This process 
continues until a block is found with all good inputs but a bad 
output. 

When this faulty functional block is identified, appropriate GFI 
hints are generated to indicate the node (or nodes) where GFI 
should start troubleshooting. 
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Figure 6-3: Identifying a Faulty Functional Block 
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DIAGNOSIS USING FAULT CONDITION 
HANDLERS 


6.3. 


Fault condition handlers provide the means for communicating 
9100A/9105A functional test failure information to the operator 
for keystroke troubleshooting or to GFI for automated 
troubleshooting. 


What are Fault Condition Handlers? 6.3.1. 

A fault condition is generated or "raised" in one of two ways: 

• A built-in TL/1 function is run, and the UUT does not 
respond correctly. For example, a microprocessor address 
line cannot be driven to logic-high during a read or write 
operation. 

• A fault command is executed in a TL/1 program. 

A fault condition handler is a TL/1 procedure, called by a fault 
condition of the same name, that responds in some way to the 
fault condition. For example, the handler might try to determine 
the cause of the fault. 

Each fault condition has a name. Fault conditions created by 
built-in functions have defined names and parameters, listed in 
TLI1 Reference Manual appendices. Fault conditions created by 
your fault commands may have any name, including the same 
name used by the built-in functions. 

When a fault condition is raised, the system halts execution of 
the current program. If your program contains a fault condition 
handler with the same name as the fault condition, the program 
statements inside the handler are executed. After the handler is 
finished, execution of your program resumes where it left off. 

If your program does not contain an appropriate fault condition 
handler, execution of the program terminates and its calling 
program (if any) is searched for a fault condition handler with 
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the specified fault condition name. This process continues until 
an appropriate handler is found. If no handler is found, a fault 
message will appear on the operator's display. 

For more information on fault condition handlers, see Section 
3.7 of the Programmer's Manual. 


Using Fault Condition Handlers 6.3.2. 

The UUT go/no-go test should test only those functional blocks 
that cannot be tested indirectly by other blocks. When the 
go/no-go test detects a failure, the diagnostic program is used to 
identify the failing block and to identify a failing node as a 
starting point for troubleshooting. 

To use fault condition handlers in a diagnostic program, you 
need to do two programming tasks for each handler: 

1. Use the fault command (with an appropriate fault 
condition that you create) to generate the fault 
condition if a test (or part of a test) of a functional 
block fails. For example, if the diagnostic program 
finds that the functional test of the video output 
circuitry fails, you might choose to generate a fault 
condition named video output. 

2. Create a handler for this fault condition. The handler 
should check other input blocks to isolate the failing 
functional block. It might also do further testing to 
narrow down the zone of failure within a failing 
functional block. And the handler will generate the 
appropriate starting point for GFI by using the gfi 
hint command. 


A Diagnostic Test Example 6.3.3. 

Suppose the video circuitry is failing. Testing begins with 
execution of the go/no-go2 program, listed in Section 6.4 of this 
manual. This program has many fault condition handlers at the 


6-9 








beginning, and it has six execute statements at the end that 
actually execute the go/no-go test. Each of these execute 
statements executes a different functional test program for a 
major functional block. And each of these functional test 
programs include the necessary fault condition handlers to 
generate GFI hints appropriate for the fault condition 
encountered (a listing for each of these programs is contained in 
Section 6.5 of this manual). The GFI hints are very important to 
the troubleshooting process; they are the means by which the 
9100A/9105A communicates the results of its functional testing 
to provide efficient starting points for GFI troubleshooting. 

Suppose that the failing video circuitry does not affect any of the 
six major functional blocks except test_video2. In this case, 
test_bus2, test_rom2, test_ram2, test_pia2, and test_rs232b all 
pass, but test_video2 fails. The test_video2 test is really the test 
of the Video Oulput functional block. If this test fails, a video 
fault condition is generated (suppose the video scan fault 
condition is generated). Since the test_video2 program has a 
handler for video scan, the program statements inside this 
handler are executed. 

Once the hints to GFI are passed, execution of the video fault 
condition handler (video scan) ends, the test program 
(test_video2) ends, and the diagnostic program (go_nogo2) 
ends. A message appears on the operator's display saying that 
GFI hints have been generated, and that GFI should be run. 

The diagnostic program is structured so that only one failure is 
isolated at a time. The problem should be isolated with GFI and 
fixed when it is detected. It is appropriate to repair an isolated 
fault before testing any further, since apparent multiple failures 
often result from one physical problem on a board. For 
example, a short between two nodes can appear as two failures. 
After a fault has been repaired, the diagnostic program should be 
run again to find other faults or to verify that no more faults can 
be found. 







DIAGNOSTIC PROGRAM FOR THE 
DEMO/TRAINER UUT 


6.4. 




program go_nogo2 

ri ! '•!! I ! I ! I!!!!! M I!!!!!!!!!!!!!! 11 !!!!!!!!!! 111 !!!!! IJ !!!!!!!!!! 11 i !!!! ! 

! The Go/No-go program is the highest level of the functional testing 
! and fault condition handlers. The purpose of the Go/No-go test is to 
! determine whether the UUT is good or bad. This program executes six 
! programs which test the six major functional blocks (Microprocessor 
! Bus, ROM, RAM, Parallel I/O, Serial I/O, and Video). By testing the 
! six major functional blocks, the remaining functional blocks are 
! indirectly tested. 

I 

! If the Go/No-go test detects a faulty UUT, further fault isolation is 
! performed to isolate which circuit is causing the failure. The fault 
I condition handlers in the Go/No-go program and the other functional 
! test programs perform the fault isolation. The fault condition 
l handlers included in this program are handlers for those fault 
! conditions which may occur during any of the six major functional 
! tests. 

t 

! The major functional test programs include fault condition handlers 
! for fault conditions which are only generated within that program. 

! The first three programs (TEST_BUS, TEST_ROM, and TEST_RAM) use 
! built-in TL/1 tests and the built-in fault condition handlers that ! 
! are documented in the 9100/9105A TL/1 Reference Manual. 


TEST PROGRAMS CALLED: 
test bus2 


test rom2 


test ram2 


test_pia2 


test rs232b 


test video2 


recover 


Test the microprocessor bus, 
buffered bus, and address 
select logic. 

Test the ROM functional block 
of the Demo/Trainer UUT. 

Test the RAM functional block 
of the Demo/Trainer UUT. 

Test the PARALLEL I/O 
functional block of the 
Demo/Trainer UUT. 

Test the SERIAL I/O functional 
block and the Interrupt 
Circuit functional block of 
the Demo/Trainer UUT. 

Test the VIDEO circuit of the 
Demo/Trainer UUT. 

The 80286 microprocessor has a 
bus controller that is totally 
separate from the pod. In 
some cases, the pod can get 
out of sync with the bus 
controller. The recover 
program resynchronizes the pod 
and the bus controller. 
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FUNCTIONS CALLED: 

retry_access (access, addr, control) This function is executed when 

a pod_timeout_recovered fault 
condition occurs. This 
function repeats the attempted 
access that failed and 
determines if the access can 
be sucessfully repeated. 

Global Variables Modified: 

recover_times Reset to Zero 

i 1111 11 m ii 1 ||it tt t t m ij ji!t j j|t M11[j11j{t 11j111111 j j 11 j 11 | t t ! ! ! t i j j 11 


!!!!!!!!!! I M !! ! 11!!!!!!!!!!!!!! II !!!!!!!!!! I!! !! M ! ! ! I!!!!!!!!!!!!! 1!!!! 
! Main Declarations ! 

!! !! M H I!!!!!!! I!! I!!!!!!!!!! I!!!!!!!!!!!!!! I!! H I!!! I!!!!! ! !!!!!! 1!!!!! 

declare 

global numeric recover_times ! Count of executing recover(). 

end declare 

m t| it i i M tt t j j t j j 1111 111 11 t j j it j j 11 11 i tt m j j j 11 t i i j j j i t t m m i i j 11!!!! ! ! 

! GENERAL PURPOSE FAULT CONDITION HANDLERS I 

t ! 

! The built-in fault conditions "pod_addr_tied", "pod_ctl_tied", ! 

! M pod_data_incorrect" and pod_data_tied are generated when the pod ! 

! detects a stuck or tied line at the pod socket. These fault ! 

! conditions are not handled because the diagnostic message for these ! 

I faults cannot be made better by additional testing. If one of these ! 

! fault conditions occurs, the built-in fault message will be displayed! 

! and the UUT needs to be repaired. ! 

! • 

i U U !!!!!!! t 11 !!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!! tt!!!!!!!!!!!!!!!!! ! 


handle pod_forcing_active (mask) 
declare string mask 
declare global numeric tlo 
declare string clear_screen = M \1B[2J" 

print on tlo ,clear_screen, "POD Forcing Lines Active fault" 
fault forcing lines mask mask ! Redirect fault 

end handle 

handle pod_interrupt_active (mask) 
declare string mask 
declare global numeric tlo 
declare string clear_screen = H \1B[2J" 

print on tlo ,clearjscreen, "POD Interrupt Line Active fault" 

! Get the last two characters of the 64 bit string mask and decode to INTR/NMI 

lines = val(mid(mask, len(mask)-3, 2),16) 
if (lines and $10) <> 0 then 
execute tst_intrpt () 
else if (lines and 1) <> 0 then 
fault NMI_active 
end if 
end handle 

handle pod_misc_fault 

fault bad_power ! Redirect fault 

end handle 
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handle pod_special 
end handle 

handle pod_timeout_bad_pwr 
declare global numeric tlo 
declare string clear_screen = "\1B[2J" 

print on tlo ,clear_screen, "POD timeout bad power fault" 
fault bad_power ! Redirect fault 

end handle 

handle pod_timeout_enabled_line (mask) 
declare string mask 
declare global numeric tlo 
declare string clear_screen = "\1B(2J" 

print on tlo ,clear_screen, "POD Timeout Enabled line fault" 
fault forcing_lines mask mask ! Redirect fault 

end handle 

handle pod_timeout_no_clk 
declare global numeric tlo 
declare string clear_screen = "\1B[2J" 

print on tlo ,clear_screen, "POD Timeout No Clock at POD Pin 31" 
execute tst_clock() ! Test Clock and Reset 

end handle 

handle pod_timeout_recovered (access_attempted, ctl, addr) 
declare string access_attempted 
declare numeric ctl = $E0000000 
declare numeric addr * $E0000000 
declare global numeric tlo 
declare string clear_screen = "\1B[2J" 
declare global numeric repeated_timeouts 

print on tlo ,clear_screen, "pod timeout recovered: " 

podsetup 'enable -ready' "off" 

podsetup 'enable hold' "off" 

podsetup 'report forcing' "off" 

repeated_timeouts = repeated_timeouts + 1 

! DISABLE all lines that can be enabled, retry access, then turn enable 
1 lines on until the access cannot be repeated. The lines that can be 
! enabled on the 80286 are Hold and Ready. 

if repeated_timeouts > 10 then 
fault dead_kernel 

else if retry_access(access_attempted, ctl, addr) fails then 
fault dead_kernel 
else 

podsetup 'enable hold' "on" 

if retry_access(access_attempted, ctl, addr) fails then 
fault hold__circuit 
else 

podsetup 'enable -ready* "on" 

if retry_access(access_attempted, ctl, addr) fails then 
execute tst_decode{) 
execute tst_ready() 
else 

print on tlo ,clear_screen 
end if 
end if 
end if 
end handle 
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handle pod_timeout_setup 
end handle 

handle pod_uut_power 

fault bad_power ! Redirect fault 

end handle 

handle iomod_dce 
end handle 

! i it] m it! j ! jm tt tt t ! m ! ! m j t 
1 Redirected Fault Handlers I 
It H !!!!!!!!!!!!!!!!!!!!! I!!! 

handle forcing_lines (mask) 
declare string mask 

declare global numeric recover_times 

! attempt to recover synchronization between pod and bus controller before 
! testing the decode, ready or clock circuits. If the recover procedure 
! has been executed at least twice, then go ahead and test decode, ready or 
! the clock circuit. 

if recover_times < 2 then 
execute recover() 
else 

lines = val(mid(mask, len(mask)-7, 8),16) 
if (lines and 1) <> 0 then 
execute tst_decode() 
execute tst_ready() 
else if (lines and $10) <> 0 then 

execute tst_clock() ! Test Clock and Reset 

end if 

! The status lines HOLD, PEREQ, BUSY and ERROR are not used in the 
1 Demo/Trainer UUT. Display a message if one of these lines is active 
! and wait for the condition to be fixed. 

loop while (lines and $E2) <> 0 
print on tlo ,clear_screen 
if (lines and 2) <> 0 then 

print on tlo ,"HOLD is active; Press RESET to continue" 
else if (lines and $20) <> 0 then 

print on tlo ,"PEREQ is active; Press RESET to continue" 
else if (lines and $40) <> 0 then 

print on tlo ,"-BUSY is active; Press RESET to continue" 
else if (lines and $80) <> 0 then 

print on tlo , "--ERROR is active; Press RESET to continue" 
end if 

wait time 2000 
end loop 
end if 
end handle 
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handle bad_power 

declare global numeric t2o 
declare string clear_screen = M \1B[2J" 
declare global string messg 
print on t2o ,messg+"FAULT DETECTED" 
loop until (readstatus () and $3D00) = 0 
fail($14) 

if (readstatus() and $3C00) = $3C00 then 

print on tlo ,clearjscreen, "POD UUT Power" 

print on tlo ,"POWER_UP and press RESET on Trainer UUT" 

wait time 2000 

print on tlo ,clear_screen, "CONTINUING..." 
else 


if (readstatus() 
if (readstatus () 
if (readstatus() 
if (readstatus() 
if (readstatus() 
end if 
end loop 
untested($14) 
end handle 


and $100) <> 0 then fault 'CAP failure at POD Pin 52' 

and $400) <> 0 then fault 'POWER failure at POD Pin 30' 

and $800) <> 0 then fault 'POWER failure at POD Pin 62' 

and $1000) <> 0 then fault 'GROUND failure at POD Pin 35’ 
and $2000) <> 0 then fault 'GROUND failure at POD Pin 9’ 


! ! ! ! ! tt ! ! ! i i i i itiiii m iiij11 m|m! t t 11j j jiiitjij j m iii i t rt t ! I i i i t i i j 111 i 

! Functions 

!!!!!!!I!!!!!!!!!!!!!!!!!!!!!!!!!! ! I!!!!!! I!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! 


function retry_access(ACCESS, ADDR, CTL) 

! Retry last access performed using parameters from fault handlers. 

handle pod_timeout_bad_pwr 
fault 

end handle 

handle pod_timeout_enabled_line 
fault 

end handle 

handle pod_timeout_no_clk 
fault 

end handle 

handle pod_timeout_recovered 
fault 

end handle 

handle pod_timeout__setup 
fault 

end handle 
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declare string ACCESS 
declare numeric CTL 
declare numeric ADDR 

if ADDR <> $E0000000 then 
address » ADDR 

else if CTL <> SEOOOOOOO then 
address = CTL 
else 

address = 0 
end if 

if ACCESS - "READ" then 

if read addr address fails then fault 
else if ACCESS = "WRITE” then 

if write addr address, data $A5C3 fails then fault 
end if 

end function 

I I!! ! I !!!!!!!!!!!!!!!!!!!!!!!!!!! I! 

! SETUP AND SYSTEM INITIALIZATION ! 

I 111!!!!!! H !!!!!!!!!!!!! I! !!!!!!!! 

recover_times = 0 
execute recover(> 


podsetup 'report power' "on" 
podsetup ’report intr' "off" 
podsetup 'report address' "on" 
podsetup 'report control' "on" 
podsetup 'report data' "on" 
podsetup 'report forcing' "on" 

! This is the go/no-go test which runs the major functional tests. ! 

! ! I!!!!!!!!!!!!!!!!!!!!!!!!! I!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!! I! ! ! ! ! 

gfi clear ! CLEAR ALL GFI RECOMENDATIONS 

connect clear "yes" ! Clear all connect information. 

execute test_bus2 () 
execute test_rom2 () 
execute test_ram2 () 
execute test_pia2 () 
execute test_rs232b 0 
execute test_video2 () 

end program 


! Recover synchronization between POD 
! and the 80288 bus controller. 

! Turn on reporting functions except 
! interrupts which is tested in the 
! SERIAL I/O test <test_rs232b). 


1 1 M M I 1 11 1 11 M t 1 t 11 1 M ! t 1 t 1 M 11 1 
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FUNCTIONAL BLOCK TESTS FOR THE 
DEMO/TRAINER UUT DIAGNOSTIC PROGRAM 


6.5. 


This section contains the following functional test programs, 
which are necessary to support the diagnostic program for the 


Demo/Trainer UUT: 


test_bus2 

Tests the Microprocessor Bus functional 
block. 

test_pia2 

Tests the Parallel I/O function block. 

test_ram2 

Test the RAM functional block. 

testjom2 

Tests the ROM function block. 

test_rs232b 

Tests the Serial I/O function block. 

test_video2 

Tests the video circuitry (the Video 
Control, Video RAM, and Video Output 
functional blocks). 


These programs are much like the programs by the same name 
found in Section 4 and used in Section 5 of this manual. 
However, these programs also contain the necessary fault 
condition handlers and gfi hint commands to tell GFI where to 
start backdating if the functional block fails. 





program test_bus2 


t t t t t I t I M I I I M I I 1 I I M t t t M I I I I I I I I ! J t l I t t 1 I 1 T I t t I t t t t r t t t t t t t ! t t t t t t t I 


FUNCTIONAL TEST of the Microprocessor Bus. 

This program tests the unbuffered microprocessor bus, performs an 
access at each decoded address of the buffered bus, and checks the 
data bus for bus contention (where a component outputs onto the data 
bus at incorrect times). If bus contention is detected then the 
program TST_CONTEN is executed. TST_CONTEN checks for incorrect 
enable line conditions on all the components on the buffered data bus. 


TEST PROGRAMS CALLED: 

tst_conten (addr, data_bits) 


Local Constants: 

Z ERO_AT_ROMO 
ZER0_AT_R0M1 
IO_BYTE 
MEM_WORD 

Local Variables Modified: 
x 

M t 1 I I I t I J I I l t I 1 I t t I t t t t t t t T t t I 1 t t t 


Test for bus contention on 
-the data bus by checking the 
enable lines of all devices 
on the data bus. 


Address of zero data in ROMO 
Address of zero data in R0M1 
I/O BYTE address specifier 
MEMORY WORD address specifier 


value returned from a read 

iit t t m t1it t t t 11 j 11t t t t t 111111 t t t t t 


Main 

III! 


!!!!!!!!!!! 

Declarations 

t t I I I ! I t I! I 


t t I I I t M It 1 1 ! ! I t t t 1 1 1 


I M M M ft ft M t t 1 II t t 1 


t t t t t t M 1 1 t t t M ? t 1 1 1 1 t 1 1 I I t II 1 


t t I t t 1 I I I t t t M t f f ft I t t J I t t f M J 


declare numeric ZERO_ATJROMO = $£002A ! Location in ROMO where 0 exists 
declare numeric ZER0_AT_R0M1 = $F0022 ! Location in R0M1 where 0 exists 

! Setup Statements 

podsetup 'enable ~ready' "on" 
podsetup 'report forcing* "on" 

IO_BYTE = getspace space "i/o", size "byte" 

MEM_WORD = getspace space "memory", size "word" 

I Test the Unbuffered Microprocessor Bus. 

testbus addr 0 

! Test the Extended Microprocessor Bus and Address Decoding. 


set space (MEM WORD) 


read addr 0 

! RAM BANK 0 

read addr $10000 

! RAM BANK 1 

write addr $20000, data 0 

! VIDEO RAM (write only) 

read addr $30000 

! INTERRUPT POLL 

read addr $E0000 

! ROM BANK 0 

read addr $F0000 

I ROM BANK 1 

setspace (IO BYTE) 


read addr 0 

! VIDEO SELECT 

read addr $2000 

1 RS232 SELECT 

read addr $4000 

! PIA SELECT 
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! Test for Bus Contention driving lines low by accessing unused address space 

setspace (MEMJWORD) 
x = read addr $50000 
if x <> $FFFF then 
execute tst_conten( 
return 
end if 

! Test for Bus Contention driving lines high by reading and writing RAM 
I If failure then check for bad RAM by reading zeros from 2 other devices. 

write addr 0, data 0 ! WRITE and READ RAM addr 0 

x = read addr 0 ! If fails then check for bad RAM 

if x <> 0 then ! by reading 0's at ROMO and ROM1 

if (read addr ZERO_AT_ROMO) <> 0 then 
if (read addr ZERO_AT_ROMl) <> 0 then 
execute tst_conten( 0, x) 
return 
end if 
end if 
end if 

end program 


! SPARE-2 ADDRESS SPACE 
$50000, cpl(x) and $FFFF) 
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program test_pia2 


T ! T T ! T I I I T T T T T ! ! ! ! ! I M M 1 I J M t I M M M J I I I t M M ! I t t I I I | I I J I I I t t I { I I It I M 

FUNCTIONAL TEST of the PARALLEL I/O functional block. 


This program tests the PARALLEL I/O functional block of the 
Demo/Trainer. The two LEDs and the four pushbutton switches are 
tested. The test operator is prompted to visually inspect the LEDs 
as the LEDs count a series of numbers. 


TEST PROGRAMS CALLED: 
abort_test (ref-pin) 


TEST FUNCTIONS CALLED: 

keys (key_number) 


If gfi has an accusation, 
display the accusation; 
otherwise create a gfi hint 
for the ref-pin and terminate 
the test program (GFI begins 
troubleshooting). 


Test Demo/Trainer pushbutton 
key key_number. Prompt test 
operator to push the key. 


leds (led_addr, led_name) 

I ! I J 11 t i i i i i i t t t i i i t i t i i t t t t t 11 ti i i i 


Test Demo/Trainer LED led_name 
which is driven by the PIA and 
has the address led_addr. 

1111 n 111 ti t m 111 1111111111111 11111 


i i m j i i!!i!iiiti m iiiiiiii!!11 jiiiiiiiii|iiiiii i i j! m i i i i i i! m i i i i i i i i i t 
! Main Declarations 

!!!!!!!!!!!!!!!!I!!!!!!!!!!!!!!!!!!!!! !!i !!! !!! !!!!!!!!!!!!!! !!!!!!! !!! I 


declare global numeric tlb ! Terml buffered output & input 

declare global numeric tli ! Terml unbuffered input 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 
! FAULT CONDITION HANDLERS: ! 

! These fault conditions are generated by the this program. These ! 

! handlers perform isolation of the faulty circuit. The handlers ! 

! which isolate the LED problems perform a GFI test on the LED. ! 

! If all signals are good and the test operator has failed the LED,! 

! then the LED is accused as a bad component. ! 

i!iit tiii t i!it t i t t j j t t i j j it j ! i j j j j t j j ! j t ! ; j it tt j j t j j t ! t j t j j ! j j i t t! j j j i j j j 


handle 'PIA LED A failed' 
declare global string rev 
declare string newline = "Xnl" 

if gfi test "U32-1" fails then 
abort_test("U32-1") 
else 

if gfi test "U33-1" fails then 
abort_test("U33-1") 
else if gfi test "U33-13" fails then 
abort_test("U33-13") 
else if gfi test "U33-10" fails then 
abort_test("U33-10") 
else if gfi test "U33-8" fails then 
abort_test("U33-8") 
else if gfi test "USS-?" fails then 
abort_test("U33-7") 
else if gfi test "U33-2" fails then 
abort_test("U33-2") 
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else if gfi test "U33-11 M fails then 
abort J:est ("U33-11’*) 
else if gfi test "U33-6" fails then 
abort_test ("U33-6") 
else 

print rev, newline,"LED A IS BAD", newline, "REPLACE LED A" 
end if 
end if 
end handle 

handle 'PIA LED B failed' 
declare global string rev 
declare string newline = "\nl" 

if gfi test "U46-1" fails then 
abort_test("U46-1") 
else 

if gfi test "U47-1" fails then 
abort_test("U47-1") 
else if gfi test "U47-13" fails then 
abort_test("U47-13") 
else if gfi test "U47-10" fails then 
abort_test("U47-10") 
else if gfi test "U47-8" fails then 
abort_test{"U47-8") 
else if gfi test "U47-7" fails then 
abort_test("U47-7") 
else if gfi test "U47-2" fails then 
abort_test("U47-2") 
else if gfi test "U47-11" fails then 
abort_test("U47-11"} 
else if gfi test ,, U47-6" fails then 
abort_test("U47-6") 
else 

print rev, newline, "LED B IS BAD", newline, "REPLACE LED B" 
end if 
end if 
end handle 


handle 'PIA KEY 1 failed 1 
abort_test("U31-14") 
end handle 

handle 'PIA KEY 2 failed* 
abort_test("U31-15"} 
end handle 

handle 'PIA KEY 3 failed' 
abort__test {"U31-16") 
end handle 


handle 'PIA KEY 4 failed 1 
abort^test("U31-17") 
end handle 
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t t I I I I I t I I M I I I M M I 1 1 M ! t J 1 t t t M | I t I I I M M I M M t M 1 ! I I I 1 I J t 1 I I I I I t ! J t | t 

! Functions 


function keys(keynum) 

declare numeric keynum 
declare string norm = "\lB[0m" 
declare string rev = H \lB[0;7m" 
declare string entry 
declare string fail = HH 
declare global numeric tlb 
declare global numeric tli 

mask - setbit(keynum - 1) 

loop until fail = chr($D) ! loop until YES key 

print on tlb ,"\nlPress ", rev," UUT KEY ", keynum," ",norm," pushbutton" 
print on tlb ,"Press any 9100 key if test is stuck" 
loop until (poll channel tli, event "input") = 1 
if ((read addr $4004) and mask) = 0 then return 
end loop 

loop until (poll channel tli, event "input") = 0 1 Flush input buffer 

input on tli ,entry 
end loop 

print on tlb ,"\nlPress ",rev," YES ",norm," to fail KEY ",keynum," test," 
print on tlb ,"Press "+rev+" NO "+norm+" to continue key test," 
input on tli ,fail 
end loop 

print on tlb ,"\nl\nl" 

fault ! Fail Key test (set termination 

end function I status of function to fail. 

I! 1 1 1!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 1!!!!!!!!!! !!!!!!!!! I M !!!!!!!!!!!!!! 


! Number of key to test. 

! Normal video escape string 
! Reverse video escape string 


function leds(led_addr, led_name) 
declare numeric led_addr 
declare string led_name 
declare string key 
declare string norm = "\lB[0m" 
declare string bold = "\lB[lm" 
declare string rev = "\lB[7m" 
declare string clear_screen = "\1B[2J" 
declare string no_auto_linefeed = "\lB[20h" 
declare global numeric tli 
declare numeric array [0:10] numbers 


numbers [0] = $C0 
numbers [1] «* $F9 
numbers [2] = $A4 
numbers [3] = $B0 
numbers [4] = $99 
NO = chr($7F) 


\ numbers [5] = $92 

\ numbers [6] = $82 

\ numbers [7] = $F8 

\ numbers [8] = $80 

\ numbers [9] = $98 

\ YES = chr ( $D) 


print norm, clear_screen, "Watch LED ", led_name, " count" 

print "Press ", rev, " ENTER ", norm, " key to start LED counting." 

input key 

print clear_screen 


for i = 0 to 9 

write addr led__addr, data numbers [i] 
wait time 500 
next 
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write addr led_addr, data $7F 
print clear_screen, "\IB[201" 

print "\lB[l;lfDid LED ", led_name, " display ALL segments off, then" 
print "\lB[2;lfdigits 0 to 9, then only the Decimal Point ?" 
print "\lB[3;fpress: "+rev+" YES ,, +norm+" or "+rev+" NO "+norm 
loop until key = YES or key = NO 
input on tli ,key 
if key = NO then fault 
end loop 

write addr led_addr, data $FF \ print no_auto__linefeed, clear_screen 


end function 


t t t t t t t t t t t t t t t t t i i i t i t t t t t j 11 t t t t t t t t t t t 11 t t t i t t t it i t t t t t t t i t t t t t 


! PARALLEL I/O Test. 

1 1 1 I I I I 1 1 1 1 I I I I I I I I I I ! I I I 


t i t t i i i i i i t t t t t t t i t t t t t t t t t it t t t 



tlb = open device "/terml", as "update", mode "buffered" 
tli = open device "/terml", as "input", mode "unbuffered" 
execute pia^init{} 

if leds($4000, "A") fails then fault 'PIA LED A failed' \ return 
if leds($4002, "B") fails then fault 'PIA LED B failed' \ return 


if keys(l) 

fails 

then 

fault 

•PIA 

KEY 

1 

failed' 

\ 

return 

if keys(2) 

fails 

then 

fault 

■PIA 

KEY 

2 

failed' 

\ 

return 

if keys(3) 

fails 

then 

fault 

'PIA 

KEY 

3 

failed' 

\ 

return 

if keys(4) 

fails 

then 

fault 

'PIA 

KEY 

4 

failed' 

\ 

return 


end program 
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program test_ram2 

tt i i i i ! i i ! ! i i i ! i i i t j i ! 111 i i i t i i m ! ! it i i tt t j i i it t t m j! t ! t ! ! ! 1 i! ti j i i t t ! ! it 

! FUNCTIONAL TEST of the RAM functional block. ! 

r t 

! This program tests the RAM functional block of the Demo/Trainer. The ! 

! TL/1 testramfast command is used to test the RAMs. If the RAMs are ! 

! found to be faulty, then one of twelve built-in fault conditions is ! 

! generated. ! 

i t 

! TEST PROGRAMS CALLED: ! 

! abort_test (ref-pin) If gfi has an accusation, ! 

! display the accusation; l 

! otherwise create a gfi hint ! 

! for the ref-pin and terminate ! 

! the test program (GFI begins I 

! troubleshooting). ! 

i i i t i i i t t t t t t t t iit r r t tit 11f tit titt 11 m m t tiiij!iiT j ! t j j j I ! i ! ! tt m j j ! i j i m 


iiiitiiit !;;m t;j!j j!i m m tit M j j tii m j! i m j ji m i i t ! I t m i i m i i ; 11! !!! ! ! 
FAULT CONDITION HANDLERS: 

Built-in testramfast fault condition handlers 
ii m iiiiiiiir m iitiiii m iiiij tt m ? i it i 11 11 m i i i i 1111 t i tt i tt j j i t i i i i t ti i 


handle ram_addr_fault (data_mask) 
declare numeric data_mask 
declare string clear_screen - "\1B[2J H 
print clear_screen 

print "\nlRAM addr line fault detected, CONTINUING" 
fault rarrjcomponent data_bits data_mask 
end handle 

handle ram_addr_addr_tied (data_mask) 
declare numeric data_mask 
declare string clearjscreen = "\1B[2J" 
print clear_screen 

print "\nlRAM addr lines tied detected, CONTINUING" 
fault ram_component data__bits data_mask 
end handle 

handle ram_addr_data_tied (datajexpected, data) 
declare numeric data_expected 
declare numeric data 

declare string clear_screen = "\1B[2J" 
print clear screen 

print "\nlRAM addr-data tied detected, CONTINUING" 
fault ram_component data_bits (data xor datajexpected) 
end handle 

handle ram_addrjdata__tied_unconfiimed (datajexpected, data) 
declare numeric datajexpected 
declare numeric data 

declare string clearjscreen = "\1B[2J" 
print clear_screen 

print "\nlRAM addr-data tied detected, CONTINUING" 
fault ram_component data__bits (data xor datajexpected) 
end handle 
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handle ram_data_data_tied (data_expected, data) 
declare numeric data_expected 
declare numeric data 
declare string clearjscreen = M \1B[2J" 
print clear_screen 

print "\nlRAM data lines tied detected, CONTINUING’* 
fault ram_component data_bits (data xor data_expected) 
end handle 

handle ram_data_fault (data) 
declare numeric data 
declare string clear_screen = ,, \1B[2J" 
print clear_screen 

print ”\nlRAM data line fault detected, CONTINUING” 
fault ram_component data_bits data 
end handle 

handle ram_data_incorrect (data_expected, data) 
declare numeric data_expected 
declare numeric data 
declare string clear_screen = "\1B[2J" 
print clear_screen 

print "\nlBAD RAM data detected, CONTINUING” 
fault ram_component data_bits (data xor data_expected) 
end handle 

handle ram__data_high_tied (data_expected, data) 
declare numeric data_expected 
declare numeric data 
declare string clear_screen = ”\1B[2J” 
print clear_screen 

print *‘\nlRAM data tied high detected, CONTINUING” 
fault ram_component data_bits (data xor data_expected) 
end handle 

handle ram_data_low__tied (data_expected, data) 
declare numeric data_expected 
declare numeric data 
declare string clearjscreen = "\1B[2J” 
print clear_screen 

print "\nlRAM data tied low detected, CONTINUING" 
fault ram_component data_bits (data xor data_expected) 
end handle 

handle ram_cell_cell_tied (data_expected, data) 
declare numeric data_expected 
declare numeric data 

declare string clear_screen = "\1B[2J" 
print clear_screen 

print "\nlRAM cells tied detected, CONTINUING" 
fault ram_component data_bits (data xor data_expected) 
end handle 

handle ram_cell_low_tied (data_expected, data) 
declare numeric data_expected 
declare numeric data 

declare string clear_screen = "\1B[2J” 
print clear_screen 

print ”\nlRAM cell tied low detected, CONTINUING” 
fault ram_component data_bits (data xor data_expected) 
end handle 







I I I I I I I I !!!!!!!! I I I I I I I I I !!!!!! I I I I I !! I I I I I I !!! I I I I !! I I I I I ! I I I I I I I !!!! ! 
Redirected fault handler 

The RAM block can fail if a problem exists with the ready circuit. 

So test the ready circuit, then if the ready circuit is good, use 
the data bits parameter passed from the testramfast built-in fault 
handlers to test the failing RAM IC. If the RAM IC is good then 
test the data bus at the bus buffers. (Testing the data bus buffer 
will detect any problem in the data bus). 

!!!!I!12!!!!!!!!!!!!!!!!!!!!!11!!!!!!!!1 111111 111!!!! ! 1!!!!!!!!!!!!!! ! I 


handle ram_component (data_bits) 
declare numeric data_bits 
declare string array [0:$15] ram_ic 


ram ic[0] = "U55" 

\ 

ram_ic[l] 

ram_ic[2] = "U53" 

\ 

ram_ic[3] 

ram_ic[4] » "U51" 

\ 

ram_ic[5] 

ram_ic[6] = "U49" 

\ 

ram_ic[7] 

ram ic[8] = "U41" 

\ 

ram_ic(9] 

ram_ic[10] = "U39" 

\ 

ram_ic[ll] 

ram_ic[12] = "U37" 

\ 

ram_ic[13] 

ram_ic[14] = "U35" 

\ 

ram__ic[15] 

If ready circuit is 

untested, then 

if(gfi status "Ul-4 

"> 

= "untested 

if gfi test "Ul- 

4" 

fails then 


end if 


= 

"U54" 

! RAMS 

U55, 

U54 

= 

"U52" 

! RAMs 

U53, 

U52 

= 

"U50" 

! RAMs 

U51, 

U50 

= 

"U48" 

! RAMs 

U49, 

U48 

= 

"U40" 

! RAMs 

U41, 

U40 

= 

"U38" 

! RAMS 

U39, 

U38 

« 

"U36" 

! RAMs 

U37, 

U36 

= 

"U34" 

! RAMs 

U35, 

U34 


check Ready circuit 
1 then 

abort_test ("Ul-4" ) 


! Check highest order ram that is failing, using ram__ic array to get refname. 


if data_bits <> 0 then 

bad_ram_ref = ram_ic[msb(datambits)] + "-1“ 
if gfi test bad_ram_ref fails then abort_test (bad_ram_ref) 
end if 


! Check Data Bus buffers. 

if gfi test H U3-2” fails then abort_test("U3-2" ) 
if gfi test "U23-2" fails then abort_test( H U23-2") 
end handle 


! j mm! t j i i mi m m ! ; MMM tt Mi m m M M t it M m j t t i! i j j mi tt t MM;!!!!! m 
! FUNCTIONAL TEST PROGRAM to test RAM CIRCUIT FUNCTIONAL BLOCKS. 

t t I I I I I I I t t t t t t t 1 ! T I r ! M M t I I I t M ! M M t t t M I ! M t t M I M t t I I M M M M t t I I t T 


! Setup 

podsetup 'enable -ready' "on" 
podsetup 'report forcing' "on" 

setspace space (getspace space "memory", size "word") 
! Main part of test 

testramfast addr 0, upto $1FFFE, delay 250, seed 1 
end program 
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program test_rom2 


!!!!!!!!!!!!! I ! M !!! t !!!!!!!!!!I!!!!!!!I!!!!!!!I!t m iit 11j m m i! r j j! j t j r 

! FUNCTIONAL TEST of the ROM functional block, 
j 

! This program tests the ROM functional block of the Demo/Trainer. The 
! TL/1 testromfull command is used to test the ROMs. If the ROMs are 
! found to be faulty, then one of seven built-in fault conditions is 
! generated. 

i 

! TEST PROGRAMS CALLED: 

! abort_test (ref-pin) If gfi has an accusation, 

I display the accusation; 

* otherwise create a gfi hint 

! for the ref-pin and terminate 

1 the test program (GFI begins 

! troubleshooting). 

!!!!!!!!!!!!!!!!!!!!!!! I!!!!!!!!!!!!!! I! m m M m t t m j | m i t t t t t j r it i i i t t t ; 

!!!!!!I! !!!!!!!!!!! I! !!!!!!! ! I!!!!!!!!!!!!!!!!!! I!! ! ! ! 

! FAULT CONDITION HANDLERS: 

! Built-in testromfull fault condition handlers 

!!!!!!!!!! I!!!!!!! III 11!! tt j!; tt i M 11 i t j j i i j i m j; M j i i 

handle rom_sig_incorrect (addr) 
declare numeric addr 
declare string clear_screen = "\1B[2J" 
print clear_jscreen 

print "\nlBAD signature detected, CONTINUING’ 0 
fault rom_component addr__bits addr 
end handle 

handle rom_addr_fault (addr) 
declare numeric addr 
declare string clear_screen - "\1B[2J" 
print clear_screen 

print "\nlRom address line fault detected, CONTINUING" 
fault rom_component addr_bits addr 
end handle 

handle rom_addr_addr_tied (addr) 
declare numeric addr 
declare string clear_screen = "\1B[2J” 
print clear_screen 

print "\nlRom address line tied detected, CONTINUING" 
fault rom_component addr_bits addr 
end handle 

handle rom_data_high_tied_all (addr) 
declare numeric addr 
declare string clear_screen = "\1B[2J" 
print clearjscreen 

print "\nlRom data all high detected, CONTINUING" 
fault rom__component addr_bits addr 
end handle 

handle rom__data_low_tied_all (addr) 
declare numeric addr 

declare string clear_screen = "\lBt2J" 
print clear_screen 

print ”\nlRom data all low detected, CONTINUING" 
fault rom_component addr__bits addr 
end handle 














handle rom_data_fault (addr) 
declare numeric addr 

declare string clear_screen = “\1B[2J M 
print clear_screen 

print H \nlRom data line fault detected, CONTINUING" 
fault rom_component addr__bits addr 
end handle 

handle rom_data_data_tied (addr) 
declare numeric addr 

declare string clear_screen = "\1B[2J" 
print clear_screen 

print "\nlRom data lines tied detected, CONTINUING" 
fault rom_component addr_bits addr 
end handle 

I! ! I ! ! I ! ! II!!!! ! I!!!!!!!! I!!!!!!!!!!!! I !!!!!!!! I!!!!!! I!!!!!!!!! !!! !! I! ! 
! Redirected fault condition handler: 

j 

! Use failing address bits parameter passed from testromfull fault 
! condition handlers to gfi test the ROM bank that failed, 

t t ! i ! t j m ; t t t it it i t m m i j i j i j t t m i j j 11 m t tt j j 11 m t t j j j i it t j i j 11 !! !! I !! ! 1 

handle rom__component (addr_bits) 
declare numeric addr_bits 

if addr_bits >= $F0000 then 

if gfi test "U27-1" fails then abort_test("U27-11") \ return 

if gfi test "U28-1" fails then abort_test("U28-11") \ return 

else 

if gfi test "U29-1" fails then abort_test ("U29-11") \ return 

if gfi test "U30-1" fails then abort_test{"U30-11") \ return 

end if 
end handle 

m j j i ! j t t t t ! ! j ! ! j j j j i t t it j M i i j ; m | j j j 11 i t ! i t j j i j ! ! m j 11 t j j ! t j j t j i i j ti m 

! FUNCTIONAL TEST PROGRAM to test ROM CIRCUIT FUNCTIONAL BLOCK 

!!!!!!!!!!!!!!!! I! II!!!!! 11! !!!!!!!!!!!!!!!!! I! I !!!!!!!!!!!!! I!!!!!!!! 

! Setup. 

podsetup 'enable ~ready' "on" 
podsetup 'report forcing' "on" 

setspace space (getspace space "memory", size "word") 

! Main part of Test. 

testromfull addr $F0000, upto $FFFFE, addrstep 2, sig $156F 
testromfull addr $E0000, upto $EFFFE, addrstep 2, sig $B61E 

end program 
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program test_rs232b 


!!!!!!!!!!!!I I!!!I!!1!!!!!!!!!!!!!!I ! I l!!!!!!!!! 11! I!!!!!!!! I I!!!!!!!! ! 
FUNCTIONAL TEST of the SERIAL I/O functional block. 

This program tests the SERIAL I/O functional block of the Demo/ 
Trainer. The two RS-232 ports are tested by setting three Dip 
Switches to loop back the two ports (SW4-4, SW4-5 and SW6-4 loop back 
ports A and B). The SERIAL I/O functional block also outputs two 
interrupt request signals. This program also checks the interrupt 
circuitry. 

TEST PROGRAMS CALLED: 

abort_test (ref-pin) Call fail for reference name 

then if gfi has an accusation 
display the accusation else 
create a gfi hint for the 
ref-pin and terminate the test 
program (GFI begins trouble¬ 
shooting) . 

frc_int () POD PROGRAM forces repetitive 

interrupt acknowledge cycles 
and returns first interrupt 
vector found on data bus. 



rd_cscd () 


rd_rearm () 


POD PROGRAM returns the 24 bit 
interrupt cascade address that 
was found on the address bus 
during the last interrupt 
acknowledge cycle. 

POD PROGRAM returns the most 
recent interrupt vector and 
rearms the pod to respond to 
the next interrupt. 


FUNCTIONS CALLED: ! 

sync_buffer (address, data) Synchronize FIFO buffer in I 


iitmi 

r i t m i tt t 111111 1 1 

ftiiit tfttfitt 

DUART to be last byte receivedI 
Receive buffer is located at ! 
the value of address. The I 

data in data is written to theI 
DUART and then read until it ! 
appears in the FIFO or count ! 
expires. ! 

? M M M t t t» M t t T tt M ! I I t t M M t t t t 1 t t t 

i t t t t t i 

1 t t t t t M 1 1 t t t I t 1 1 

riTtTTTTTItflf 

1 t t I I t M t t l 1 1 f r t 1 t ! t t f t t 1 t t t t 1 1 t r l t t t 

! Main 

i i t t t t i 

Declarations 

i i t t t t t t t i t i ii t i i 

1 T I t t t 1 1 ? I 1 t 1 ! 

t t 111 » t i t 11 t i t r 111 i m t r t 111 m r t t t t t r t 


declare 

string q 
string rev 
string norm 
end declare 


"VLB[0;7m" 
"\lB[0m" 


! used to get input from keyboard 
! Reverse Video escape sequence 
! Normal Video escape sequence 
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t ; M m ! ! ! ! ! ! i i ! r r I ! tt ! m m t t i ! i i it i ! m i i t M !! ! i i i ! t j m i i t t; ! t M m i M m ! 
FAULT HANDLERS: 

These fault conditions are generated by the this program. These 
handlers verify the failure using the Probe or I/O Module and 
then pass control to GFI. 

i iii11111!i11111(ii!ii!j j!ii!!!!!!!!!!]j !!!!!!!!!! m i !!!!!![! |!!!!!!!! ! 


handle ‘RS232 Port A failed* 

if gfi test "Ull-35" fails then abort_test("Ull-35”) 
end handle 

handle 'RS232 Port B failed* 

if gfi test "U11-5 M fails then abort_test {'*Ull-5") 
if gfi test "Ull-11" fails then abort_test (**U11-11*') 
end handle 

handle 'Interrupt failed* 

if gfi test H U10-2" fails then abort_test (**U10-2 M ) 
if gfi test "U20-9" fails then abort_test("U20-9") 
end handle 

!!!!!!! j !!!!!!!!!!!!!! t m ! t MM!!;;! j j t mm! m MMMM j MM!!!!! t MM!;; i 

! FUNCTIONS ! 

!!!!!!! I I! !!!!!!!!!!!!!!!!! I !!!!!!!! I!!!!!!!!!! !!!!!!I!I!!!!!!!!!! !!!!!! ! 

function sync_buffer( address, data ) 
declare numeric address 
declare numeric data 

! Synchronize FIFO buffer in DUART. Write and then read until correct data 
! is returned or count has expired. 

write addr address, data data ! Transmit Data 31 on port A 

wait time $200 
cnt =0 \ x = 0 

loop until x = data or cnt > 3 
x = read addr address 
cnt = cnt + 1 
end loop 
end function 

!! !! ! 11 ! I!!!!!! !! I!!!!!!!!!!!!!!!! !!!!!!! I!!!!!!!!!!!!!! !!!!!!!!!!!!!! ! ! ! 

! FUNCTIONAL TEST of the SERIAL I/O Functional Block. I 

!!!!!!!! H !!!!!!!!!!!!!!!! I!!!!!!!I!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !! 

! Set interrupt acknowledge cycles on and use the 80286 
! pod specific programs rd_rearm(), frc_int() & rd__cscd(). 

podsetup 'report intr* "off" 

podsetup *intr_ack on* i Enable Interrupt Ack. cycles 

option = getspace space "i/o", size "byte” 
setspace (option) 
execute check_loop() 

execute rd_rearm() ! Clear interrupts 
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! Main part of Test. Verify DUART port A. 

sync_buffer( $2006, $61 ) ! Synchronize FIFO in DUART for port A 

write addr $2006, data $55 ! Transmit Data 31 on port A 

wait time $200 

if {(read addr $2002) and $F) <> $D then fault 'RS232 Port A failed' \ return 
if (read addr $2006) <> $55 then fault 'RS232 Port A failed' \ return 
write addr $2006, data $55 ! Transmit Data 31 on port A 

wait time $200 

if ((read addr $2002) and $F) <> $D then fault 'RS232 Port A failed* \ return 
if (read addr $2006) <> $55 then fault 'RS232 Port A failed* \ return 

! Verify DUART port B and interrupts. 

sync_buffer( $2016, $61 ) ! Synchronize FIFO in DUART for port B 

write addr $201E, data $FF ! set output port low 

write addr $2016, data $31 ! Transmit Data 31 on port B 

if frc_int{) <> $22 then fault 'Interrupt failed* \ return 
if rd_cscd() <> $2016 then fault 'Interrupt failed' \ return 
if (readstatus {) and 8) <> 8 then fault 'Interrupt failed' \ return 
if (read addr $2016) <> $31 then fault 'RS232 Port B failed' \ return 
if frc_int() <> $27 then fault 'Interrupt failed' \ return 
write addr $201C, data $FF 

if ((read addr $201A) and 2) <> 0 then fault 'RS232 Port B failed* \ return 
end program 
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program test_video2 


!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! I!!! I!!!!!! I!!!!!!!!!! I! !!! I !! 
FUNCTIONAL TEST of the VIDEO functional block 

This program tests the VIDEO functional block of the Demo/Trainer. 

The video test uses the gfi test command to run stimulus programs and 
to check the outputs of the Video circuit against the stimulus program 
response files. The gfi test command returns a passes status if all 
the measured results from running the stimulus programs match the 
response files. Otherwise the gfi test command returns a fails 
status. 


I 


TEST PROGRAMS CALLED: 
abort_test (ref-pin) 


If gfi has an accusation, 
display the accusation; 
otherwise create a gfi hint 
for the ref-pin and terminate 
the test program (GFI begins 
troubleshooting). 

tst_vidctl () Test program to test the video 

control functional block 
outputs. Returns passes 
termination status if 
functional block is good else 
return fails termination 
status. 

tst_vidram () Test program to test the video 

RAM functional block outputs. 
Returns passes termination 
status if functional block is 
good else return fails 
termination status. 

t t 1 I M I I t t 1 t 1 t I t » t I It t 1 I 1 I I ] M M J t I t t t M J J I ! I t t t 1 I t I t ! t t I J I I 1 I M I I I I 


!!!!!!!!!I!!11!! !!I!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!! I!!!!!!!!!! ! 
FAULT CONDITION HANDLERS: 

These fault conditions are generated by the this program. These 
handlers isolate the failure in the video circuit to the Video 
control section. Video RAM section or the Video output section. 
Once the failing Video subsection has been identified, then GFI 
is started. 

i j j j j j !!!!!!!!»!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!I !!!!!!!!! I!!!!!!!!!! ! ! ! ! ! 


handle video_output 

! IF Video Control section is bad, tst_vidctl will start GFI. 
if tst_vidctl() fails then return 

! IF Video RAM section is bad, tst_vidram will start GFI. 
if tst_vidram() fails then return 

! Video Control and Video RAM have passed. Video Out is bad. Start GFI. 

abort_test("J3-9 M ) 
end handle 
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handle video_scan 

gfi hint "J3-8" 
gfi hint "J3-9 H 

fault 'gfi hints generated' 1 please run gfi' 
end handle 


!! i !!!!!!!! I!!!!!!!!!!!! 1!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1!!!!!!!!!! ! 
! FUNCTIONAL TEST of the VIDEO Functional Block. ! 

!!!!!! II I 1 I !!!!!!!!!! I ! I !!!!!!!!!I !!!I!!!!!!I!!I!!!!!!1!!!!!!!II!!!!!!!! ! 

! Setup and initialization. 

connect clear "yes" 
podsetup 'enable -ready' "on" 
print "\nl\nl" 

! Main part of Test. 

if gfi test "J3-8" fails then fault videojscan \ return 
if gfi test "J3-9" fails then fault video_scan \ return 

if gfi test "U78-11" fails then fault video_scan \ return 
if gfi test "U78-28" fails then fault video_output \ return 
if gfi test "U78-29" fails then fault video_output \ return 
if gfi test "J3-7" fails then fault video_output \ return 


end program 
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Section 7 

Troubleshooting 


After a failing functional block is isolated with a diagnostic 
program, Unguided Fault Isolation (UFI) or Guided Fault 
Isolation (GFI) troubleshooting can be used to backtrace to the 
bad node or component. 


UNGUIDED FAULT ISOLATION (UFI) 7.1. 

UFI troubleshooting is valuable when you need experience with 
stimulus programs before expanding to the GFI environment. It 
lets you use stimulus programs to determine whether a node is 
good or bad, without having to enter a node list for the UUT. 

UFI is used in a manner similar to GFI: the GFI key on the 
operator's keypad begins the process. Unlike GFI, UFI is 
designed to test only output pins. When testing with the probe, 
the output source for a node can be characterized and the other 
points on the node (such as inputs) can be probed looking for 
the same response. However, when testing with the I/O 
module, only the output pins can be measured because the other 
pins on the node are connected to I/O module pins different from 
the pins UFI thinks it should be measuring. 

When an operator needs to troubleshoot boards before the GFI 
database is developed, he can use stimulus programs in UFI 
mode while waiting for GFI to be completed. However, he 
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needs to understand the UUT since UFI does not recommend 
the next location to test. 


GUIDED FAULT ISOLATION (GFI) 7.2. 

The 9100A/9105A's built-in GFI algorithm guides an operator 
in diagnosing a faulty circuit to the component or node level 
without assistance from a skilled technician. 

Once a functional test or larger diagnostic program has generated 
a list of suspect nodes, GFI troubleshooting can begin. The 
GFI key on the operator's keypad starts the process. GFI 
begins with a bad output and tests the suspect node. Nodes are 
exercised with a stimulus program and determined to be good or 
bad by comparing their measured response to responses learned 
from a known-good UUT. 

When a node is bad, GFI tests the inputs which affect that node 
and recommends which node to test next. If the output of a 
component is bad and all inputs to the component are good, GFI 
accuses the component of being bad or the output node of being 
loaded. The node may be shorted to another node or a defective 
component may be loading the node. If an input is bad and the 
output source for that node is good, GFI accuses the node of 
having an open circuit. 

The GFI capability is general enough to troubleshoot most 
digital circuits. To apply GFI to a particular UUT, however, 
you will need to supply UUT-specific information to the GFI 
database for that UUT. The files used for this database are 
summarized in Section 7.5 of this manual and described fully in 
the Guided Fault Isolation section of the Programmer's Manual. 


STIMULUS PROGRAMS 7.3. 

Stimulus programs are TL/1 programs used by GFI or UFI to 
exercise UUT nodes in such a way that responses at the nodes 
can be analyzed and compared to responses of nodes on a 
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known-good UUT. A typical stimulus program consists of up 
to 6 main parts: 

1. (As required) - Initialize the UUT and define the 
measurement device. 

2. (As required) - Setup of the pod, probe, or I/O 
module. 

3. Use the arm command to start the measurement of 
the node response. 

4. Use any commands necessary to apply the stimulus. 

5. Use the readout command to end the measurement of 
the node response. 

6. (As required) - Restore any conditions altered by the 
setup step above (step 2). 

Stimulus programs should satisfy three very important criteria: 

• The program must be independent, initializing the UUT as 
required. This is because GFI can begin backtracing at 
any node, and the state of the UUT, prior to running the 
stimulus, is unknown. The program must also restore 
any adjustments it makes to the calibration offset. 

• During stimulus execution, only one pin should drive a 
node: that is, during the period between the arm and 
readout commands, one and only one pin should be a node 
signal source (data should flow in only one direction). 

• There should be at least one stimulus program for each 
output to the node. 

See the "Stimulus Programs" section in the Programmer's 
Manual for more detailed information on stimulus programs. 
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STIMULUS PROGRAM RESPONSES 


7.4. 


Both UFI and GFI select the appropriate stimulus programs to 
exercise a node to be measured and compare the actual response 
at the node with a stored response from a known-good UUT. 
These responses may be any of the following (or combinations 
of them): 

• CRC Signature. 

• Transition Count. 

• Frequency. 

• Asynchronous Level History. 

• Synchronous Level History. 

The information below summarizes each of these response 
measurements. See the Guided Fault Isolation section of the 
Programmer’s Manual for more complete information. 


Learning Responses From a 

Known-Good UUT 7.4.1. 

The 9100A editor's LEARN function is used to learn a set of 
responses measured on known-good UUT nodes. Once a 
stimulus program is written to exercise a node, a response file 
can be generated. To do this, the 9100A is commanded to learn 
responses at a node or set of nodes and the system prompts the 
operator to connect the measurement device (probe or I/O 
module) to the component providing the node signal source. 
The 9100 A makes a series of measurements and determines the 
characteristics. It learns the response with three measurements 
(early, normal, and late clock or sync events) to make sure the 
response is stable and that the measurement can be used as a 
reliable characterization of that node. 

Node characterization may use one or more of five 
characteristics to determine whether the node is good or bad. 
You can select which of the five should be saved in a response 
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file. GFI and UFI use these saved characteristics to determine 
whether a node is good or bad. 


CRC Signatures 7.4.2. 

It is very important to ensure that a CRC signature used in node 
characterization will properly identify all good UUTs, at all 
measurement temperatures and power supply levels. A marginal 
signature occurs when the measured node changes state near the 
clock transition or when the Start, Stop, or Clock signals are not 
stable. A marginal signature may appear stable on one UUT and 
thereby lead to a false sense of security. Other UUTs may yield 
different signatures because of temperature or power supply 
variations. 

When the 9100A editor learns a signature, it attempts to identify 
marginal CRCs by collecting signatures with advanced clock 
edges, normal clock edges, and delayed clock edges. If a 
signature has the same value for advanced and normal clock 
edges, it will be suffixed by a sign. If a signature has the 
same value for normal and delayed clock edges, it will be 
suffixed by a"+" sign. If all three values agree, the signature is 
displayed with no qualification. 

A variable signature results if the Start, Stop, or Enable signals 
are irregular, compared to the Clock signal. In addition, since 
the Start, Stop, and Clock signals are edge-triggered, unstable 
signatures will result if the Start or Stop signal edge occurs at the 
same time as the Clock signal edge. 

Figure 7-1 shows how to test whether the start/stop interval is 
stable. Connect the Clock to the clock signal you want to use. 
Connect the probe or I/O module to a logic-high level and 
connect the Start and Stop lines to the locations where you 
would connect these lines when making the signature 
measurement. If the start/stop interval is stable, a constant 
number of clocks will occur between the start and stop 
condition, and the signature will be constant. If the CRC 
signature is not constant, the start/stop interval is unstable. 
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Figure 7-1: Testing for Start and Stop Stability 










Unstable signatures may also be caused by Start or Stop signal 
edges which occur at the same time as the Clock signal edge or 
by Start or Stop signals which are asynchronous to the selected 
clock signal. Use an oscilloscope to determine whether a line is 
irregular or whether a timing problem exists between the Clock 
signal and the Start or Stop signal. 

If unstable signatures are caused by Start or Stop signal edges 
which occur at the same time as the Clock signal edge, select the 
other Clock edge (+ or -) and use the getoffset and setoffset 
TL/1 commands to adjust the measurement timing. 




Other Characterizations 7.4.3. 

Some circuits are difficult to characterize by a CRC signature. 
The node may have regular activity but there might be no signal 
which can be used as a clock to gather a consistent signature. In 
many such cases, nodes can be characterized by using transition 
counts. 

The transition count works on asynchronous signals. The 
transition count can monitor information that the CRC will not 
detect, such as extra transitions between CRC clocks. The 
transition count will typically be a range of counts, defined by a 
minimum and maximum, that represents the extremes of the 
three measurements taken by the LEARN function. Only low- 
to-high transitions are counted (not high-to-low). When the 
measurement is synchronized to the external lines, the data input 
is gated with the enable line, if used. A count of zero will result 
if the enable-true window does not overlap the low-to-high 
transition of the data. 

The frequency of a signal may be more important than its CRC 
or transition count. This is especially true for system clocks. If 
a system clock is run at 4 MHz rather than 8 MHz, everything 
on the board could appear to be good. However, when the 
board is plugged into a system, the board running at 4 MHz may 
cause a system failure. Frequency is also important for video 
signals such as horizontal and vertical sync. 
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Level history is an important characterization parameter when 
combined with signatures or transition counts. If a faulty node 
has the correct timing but swings between ground and an invalid 
level for part of the time, measuring asynchronous level history 
would detect this fault, which will be missed if only a CRC is 
measured. 

Consider the case where a node that should go high and low is 
stuck on a faulty UUT. Using both CRC and asynchronous 
level history to characterize the node will provide more complete 
information to the technician who repairs the board. The 
operator can see that the line is stuck when it should be 
changing. 

Level history can be used to detect glitches. If the measurement 
period is set so that a signal is either high or low during 
measurement, with no glitches, the level history will show only 
high or low. If the level history shows both high and low, a 
glitch has occurred. 


Calibration of the I/O Module and Probe 7.4.4. 

Whenever the pod performs a microprocessor operation, it 
generates a synchronization pulse which the 9100A/9105A uses 
to measure signatures and clocked levels. The synchronization 
pulse can be generated by several devices, including the pod or 
an external clock. 

In order for the system to measure critical signals reliably, each 
measurement device (I/O modules and probe) must be calibrated 
to this synchronization pulse on the system where it will be 
used, since each measurement device contains its own 
electronics that affect timing. If your tests must be accurate to 
within a few tens of nanoseconds on signal edges, calibration 
should be done. 

The procedures for calibration are given in the Technical User's 
Manual. Calibration should be performed for each measurement 
device and for each synchronization mode of that device on the 
particular 9100A/9105A system where it will be used. For 
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example, the probe for an 80286-based UUT should be 
calibrated to EXT, POD ADDR and POD DATA on the 
9100A/9105A where the probe will be used. 


Calibration is UUT-dependent. For this reason, calibration 
settings should be saved under the specific directory for that 
UUT. If calibration is not performed, default calibration values 
will be used. These default calibration values will only work 
properly in some UUTs (those which have ample timing margin 
or which operate at slow speeds). 




Adjusting Sync Timing 7.4.5. 

The sync pulse that the measurement devices (I/O modules and 
probe) receive from the 9100A/9105A comes either from the pod 
or an external clock signal. The pod may provide sync pulses 
with different timings relative to microprocessor read/write 
operations, depending on the synchronization mode of the pod. 
For example, the 80286 pod has POD ADDR and POD DATA 
sync modes. The sync pulse in POD ADDR mode is earlier than 
in the POD DATA mode. See the timing diagram in the pod 
manual for the pod you are using. 

Most signals on a UUT can be characterized using the external 
or pod sync mode. However, in some cases, the sync pulse 
occurs at a different time than when the signal should be 
measured. 

The getoffset and setoffset TL/1 commands can be used to adjust 
the time when a signature or clocked level measurement is made, 
relative to the sync pulse. Figure 7-2 shows how this offset is 
implemented in the probe or the I/O module. The data to be 
measured passes through one delay line and the sync pulse 
passes through a different delay line. One of the delay lines is 
variable. By adjusting the variable delay line, the data is 
measured at a different time relative to the sync pulse. 

Section 3 of the TL/1 Reference Manual contains details about 
the getoffset and setoffset commands, including the 
approximate timing resolutions of the probe and the I/O module. 


I 
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I/O Module Line or Probe 


Measurement Line 
(Probe Tip or 
I/O Module Line) 


Clock or 
Sync Pulse 



Results of 
Measurements 


Figure 7-2: Synchronization-Pulse Delay Mechanism 


7-10 







Appendices C and E of the Technical User's Manual contain 
additional timing specifications for the pod, probe, and I/O 
modules. The Supplemental Pod Information for 9100A/9105A 
Users manual and the pod manuals have more detailed 
information about pods. 

When a program adjusts the sync timing, the original timing 
should be restored at the end of the program. This can be done 
by storing the result of a getoffset command, adjusting the 
timing with setoffset, and readjusting the timing with setoffset at 
the end of the program with the stored getoffset value. 

Dynamic RAM circuits usually require sync timing adjustment in 
order to measure the RAS and CAS signals, which do not 
necessarily coincide with the POD ADDR or POD DATA sync 
pulses. The Demo/Trainer UUT stimulus programs for the 
Dynamic RAM Timing functional block show one way to adjust 
the sync timing. 


THE UUT DESCRIPTION 7.5. 

The UUT description, which provides the 9100A/9105A with 
information used for GFI and UFI, consists of: 

• Reference designator list (reflist). 

• Part Library (part descriptions). A basic part library is 
provided with the system. 

• Node list (net list or wire list). 

The Programmer's Manual provides detailed information about 
this database and how GFI and UFI use it. The following 
sections are simply a brief overview. 


Reference Designator List (REFLIST) 7.5.1. 

The reference designator list establishes the relationship between 
reference designators (such as "U80") and a part or component 
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type (such as 7410). It also specifies the testing device (probe 
or I/O module) to be used on the component. 

A sample Demo/Trainer UUT reference designator list is shown 
in Appendix A. GFI and UFI both require the reference 
designator list to determine the device needed to test a 
component. 

No distinction is made between families of components, such as 
74LS00 or 74HCT00. The Fluke-supplied part library uses 
generic names like 7400 and 7432, so when you make entries in 
a reference designator list you will need to use generic names. 


Part Library (Part Descriptions) 7.5.2. 

The part library is a group of files (part descriptions) that 
describe UUT components. A part description specifies each 
pin to be an input, output, bidirectional, ground, power, or 
unused. Each output has a list of related inputs which affect that 
output. The library can be accessed through any UUT directory. 
A basic part library is supplied by Fluke. You can add part des¬ 
criptions, including custom designs. 

See the Guided Fault Isolation section of the Programmer's 
Manual for examples of part descriptions. 


Node List (Net List or Wire List) 7.5.3. 

The node list specifies interconnections between reference 
designators. The list is only necessary for GFI, which uses it to 
backtrace between components. 

A complete node list contains one line for each node in a UUT. 
The pins on one line are all connected to form a node. Lines 
may be continued on the next line with the backslash (\) 
character. 
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Appendix B contains a node list for the Demo/Trainer UUT. 
Reviewing this example will be helpful to you when developing 
you own node lists. 


Bus-Master Pins in a Node List 7.5.4. 

The 9100A normally determines the flow of data from the node 
list; it assumes that data can be sent from any pin to any other 
pin on a given node. However, sometimes two pins are 
connected together by a node but do not actually communicate 
with each other; this situation commonly arises in bus-oriented 
systems with many components connected to a common 
microprocessor data bus. 

In such cases, you need to let GFI know that only some pins 
(called bus-master pins) can communicate with all the other pins 
on the same node. This is done by entries in the optional 
*masters section of the node list. 

The *masters section is optional, and for most UUT node lists it 
can be omitted. Where it is needed, it usually contains just a 
short list of pins, because most nodes have only a single source. 
It is only for nets such as the one in the following example that 
the *masters section becomes important. 

Consider the node shown below: It consists of bit 0 of a 
bidirectional data bus connecting several components to a 
microprocessor. 



U18 U72 U9 U31 
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Only pin U25-15 can talk to all other input pins on the node and 
only U25-15 can receive from all other output pins on the node. 
Either condition would be sufficient to make U25-15 a bus- 
master pin. 

For this reason, pin U25-15 is shown as a bus-master pin in the 
partial node list below. It is listed in the regular section of the 
node list and is also included in the optional *masters section of 
the node list. 


U8-12 U3-9 U42-21 

U25-15 U19-8 U22-2 U9-10 U31-11 

U17-4 U28-5 U27-6 


*masters 

U25-15 


See the Node List section in the Programmer's Manual for more 
information about bus-master pins. 


Choice of Backtracing Path 7.5.5. 

If there are two or more stimulus programs available for a node, 
GFI will attempt to use the program that stimulates all of the 
node's outputs (and related inputs) before using programs that 
stimulate only some of the node's pins. 

Here are three cases that relate to the AND gate in Figure 7-3. 
Each case shows the test results from two stimulus programs, A 
and B, and the conclusion that GFI comes to: 
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Figure 7-3: Direction-Control Example 
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Case 1: 

Input 1 

Input 2 

Output 3 

Stimulus Program A 

good 

good 

bad 

Stimulus Program B 

— 

bad 

bad 

GFI will accuse the node of being bad because stimulus 
program A covers all the nodes and is therefore evaluated 

first. In this case 
executed. 

stimulus 

program B 

will not be 

Case 2: 

Input 1 

Input 2 

Output 3 

Stimulus Program A 

bad 

good 

bad 

Stimulus Program B 

— 

bad 

bad 

GFI will test the component connected to input 1, again 
because stimulus program A covers all the nodes and is 
therefore evaluated first Therefore, GFI will backtrace to 

the Bus Buffer. 




Case 3: 

Input 1 

Input 2 

Output 3 

Stimulus Program A 

good 

good 

good 

Stimulus Program B 

- 

bad 

bad 


GFI will test the component connected to input 2, because 
stimulus program A finds no problem and the system goes 
on to evaluate stimulus program B. Therefore, GFI will 
backtrace to the DMA circuit. 

Consider these two problems in Figure 7-3, in which both the 
microprocessor and the DMA controller are both *master 
components: 

• If the problem is in the microprocessor, evaluation is the 
same as for Case 2, above, and GFI troubleshooting traces 
back to the microprocessor from input 1 of the AND gate. 

• If the problem is in the DMA controller, evaluation is the 
same as for Case 3, above, and GFI troubleshooting traces 
back to the DMA circuit from input 2 of the AND gate. 
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While you can effectively steer GFI by designing stimulus 
programs to cover all or only some inputs and outputs, you do 
not usually need to worry about control of the backtracing path; 
it is only needed in special circumstances. 

Normally, you should design stimulus programs that test all 
inputs and outputs of a node or component. If there is no single 
stimulus program that covers all inputs and outputs, the 
9100A/9105A uses these criteria to determine status: 

• If ANY stimulus program gives a BAD response on a pin, 
the pin is considered BAD. 

• If ALL stimulus programs give GOOD responses on the 
pin, the pin is considered GOOD. 

• Otherwise, the pin is considered UNKNOWN. 


SUMMARY OF GFI COVERAGE 7.6. 

The 9100A provides a convenient means to check the 
completeness of the information you have entered into the GFI 
database for a particular UUT. When viewing the UUT 
directory display, you can press the SUMMARY softkey to 
request generation of a summary of GFI coverage for that 
particular UUT. The compiled database (GFIDATA or 
UFIDATA) will be examined and a summary will be generated, 
displayed on the monitor, and stored in a UUT text file that you 
specify. If you press the Shift key on the programmer's 
keyboard and the SUMMARY softkey, the summary will appear 
on the monitor without sending a copy to a text file. 


Creating a Summary of GFI Coverage 

The following procedure is used to generate a Summary of 
GFI Coverage for a UUT: 

1. Press the EDIT key on the operator's keypad to enter 

the Editor (unless you are already in the Editor). 
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2. Use the EDIT key on the Programmer’s Keyboard to 
enter the name of the UUT so that the UUT directory 
for this UUT is displayed on the monitor. The UUT 
directory you have selected must contain a compiled 
database (either GFIDATA or UFIDATA). 

3. Press the SUMMARY Softkey (F8) and the 9100A 
will issue the prompt shown below to ask for a text 
file name: 

Generate GFI Summary to TEXT file _ 

The Summary of GFI Coverage to be generated will 
be stored in this text file. 

4. Type in the text file name you wish and press the 
Return key. The 9100A will then begin generating 
the Summary of GFI Coverage for the UUT and will 
display the results on the monitor. 

When the generation is complete, the following message will 
appear on the monitor: 


Press Msgs key to continue 

When you press the Msgs key on the programmer's keyboard, 
the UUT directory display will reappear on the monitor. You 
can use the Edit key on the programmer's keyboard to access the 
text file you generated. 
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o 


Statistical Summary 



The first part of the Summary of GFI Coverage is a statistical 

summary of the UUT, based on the GFI database you have 

provided. Figure 7-4 shows a typical example of such a 

summary. Each entry in the summary is described below: 

• Summary for /<disk drive>/<UUT>: In Figure 7- 
4, HDR is the disk drive and the UUT directory name is 
EXAMPLE. 

• Parts: The number of unique part types in the UUT, 
based on the reference designator list. 

• Reference Designators: The number of reference 
designators in the UUT, based on the node list. 

• Connected Pins: The number of UUT pins that are 
connected to other pins on the UUT, based on the node 
list. 

• Unconnected Pins: The number of UUT pins that are 
not connected to any other UUT pins, based on the node 
list. 

• Total Pins: The total number of pins on the UUT. 

• Programs: The number of TL/1 programs that can be 
used by GFI as stimulus programs. This number is equal 
to the number of response files. 

• Testable Connected Pins: The number of connected 
pins that can be tested by GFI. Testable pins have either 
been characterized with LEARN, or are a member of a 
node that has been characterized with LEARN. 

• Testable Unconnected Pins: The number of 
unconnected pins that can be tested by GFI. Testable 
unconnected pins have been characterized by LEARN and 
appear in a response file. 

• Total Testable Pins: The total number of UUT pins 
that can be tested with GFI, given the database you have 
entered. 
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Summary for /HDR/EXAMPLE: 

53 Parts 

167 Reference Designators 
1694 Connected Pins 
225 Unconnected Pins 
1919 Total Pins 
42 Programs 

1688 Testable Connected Pins 
16 Testable Unconnected Pins 
1704 Total Testable Pins 

6 Untestable Connected Pins 
209 Untestable Unconnected Pins 
215 Total Untestable Pins 

99% Test Coverage of Connected Pins 
88% Test Coverage of Total Pins 


Figure 7-4: Statistical Summary Display for a UUT 






• Untestable Connected Pins: The number of 
connected pins that cannot be tested with GFI, due to an 
incomplete database. 

• Untestable Unconnected Pins: The number of 
unconnected pins that cannot be tested with GFI, due to an 
incomplete database. 

• Total Untestable Pins: The total number of UUT pins 
that cannot be tested with GFI, given the database you 
have entered. 

• Test Coverage of Connected Pins: The percentage 
of connected pins on the UUT that can be tested with GFI, 
given the database you have entered. A figure of less than 
100% indicates an incomplete database. 

• Test Coverage of Total Pins: The percentage of 
UUT pins that can be tested with GFI, given the database 
you have entered. This figure is typically less than 100% 
because a UUT often has unused pins. 


Pin Coverage 

The second part of the GFI Summary of Coverage display is a 
matrix showing how component pins are tested with the 
database you have provided. Figure 7-5 shows a partial 
example of a pin coverage matrix. The matrix is organized with 
the reference designators listed vertically (in the left-most 
column) and with component pin numbers listed horizontally. 
The number of pins per line will be the number required by the 
largest component in the list. If more than 35 pins are required, 
the display will produce a second list of reference designators 
following the first list and this second set will have pin numbers 
starting with 36 and continuing up from there. 

Each component pin has a one-character symbol that shows how 
GFI looks at the pin given the database you have provided. The 
table at the bottom of Figure 7-5 shows the meaning of each 
symbol that is possible: 
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Pin Coverage: 


11111111112222222222333333 

12345678901234567890123456789012345 



10. 

II.. 

10 .. 

I * * I I * * * I * * I I I I I I I I I I I I I I I I I I I I I I I I 

IIIII. 


Oil. 

0 1 . 

10. 

10. 

II. 

II. 

IIIIIBIIBIIBIIBBIIBI. 

*I*IIII*III*000*0BBBBI*0BBBB****0*I 

OOIOIOOIOIIOIOII. 

IOIOIOGOIOIOIP. 

0 ** 00 *** 1**000000000000000001110001 


Symbol 


Meanm 


I The pin is testable as an input only. 

O The pin is testable as an output only. 

B The pin is testable as both an input and an output. 

P The pin is testable as a power pin. 

G The pin is testable as a ground pin. 

* The pin is not testable (because it has no associated 
stimulus program or no known-good 
response stored for this pin). 

There is no such pin in the database. 


Figure 7-5: Pin Coverage Display for a UUT 
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FAULT CONDITION EXERCISERS 7.7. 

When the 9100A/9105A detects a fault, and a fault condition 
handler is not defined for the fault condition raised, a fault 
message will appear on the operator's display. At this point, the 
operator can press the LOOP key on the operator's keypad to 
repeatedly reproduce the fault so that it can be isolated manually. 
To do so requires that a fault condition exerciser exist for the 
fault condition that was raised. If the exerciser exists, it is 
invoked continually until the operator presses the STOP key on 
the operator's keypad. 

A fault condition exerciser is a software block designed 
specifically to reproduce a fault condition in a UUT. Two types 
of exercisers are available: built-in exercisers and user-defined 
exercisers. 

When a fault condition is raised by a built-in stimulus function 
(such as read, write, ramp, toggle, or rotate) or a built-in test 
function (such as testbus, testramfast, testramfull, or 
testromfull), the 9100A/9105A has a pre-defined sequence of 
commands that exercise the fault when the LOOP key is pressed. 
These are called built-in fault condition exercisers. In addition, 
you as a programmer can write your own fault condition 
exercisers for fault conditions that you define or to replace the 
built-in fault condition exercisers. When one of these fault 
conditions is encountered and the LOOP key is pressed, the fault 
condition exerciser with the matching name is invoked. 

If a fault condition exerciser for the displayed fault condition is 
found when the LOOP key is pressed, the fault condition 
exerciser is invoked repeatedly to stimulate the UUT. This 
allows the probe to be used to examine node responses in the 
circuit and to trace faulty circuit operation to its cause. 
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REPAIR AFTER TROUBLESHOOTING 


7.8. 


When GFI terminates, it will often display one of the following 
messages: 

• Open circuit. 

• Bad IC or output loaded. 

When GFI reports an open circuit, it has found an input which is 
bad even though the signal source on that node is good. To 
repair the node: 

1. Retest both ends of the node to make sure the output 
was properly probed. 

2. Confirm the open circuit with an ohmmeter. 

3. Trace along the node with the ohmmeter until the 
open point is found. 

4. If the node is connected properly, check for: 

An error in the node list entry for the failed node. 

Marginal measurements due to the frequency or 
timing of signals on the node. Ringing may be 
occurring on the node, or the time between the 
sync and the signal transitions may be marginal. 
Change the stimulus setup or the sync timing to 
correct the problem (see Section 8.5 on adjusting 
sync timing). 

When GFI reports a bad IC or output loaded, it has found all 
good inputs and one or more bad outputs. In this case, 
determine whether the part is bad or the output is loaded. To do 
this, test the component by overdriving its inputs with the I/O 
module while measuring level history or CRC signatures. 
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In doing so, determine whether: 

• The level history showed that the line went to a high and 
low state. If so, the node is only loaded part of the time, 
or the component is bad. 

• The node is loaded. If the component is good but the node 
is bad, the node must be loaded. The cause of a loaded 
node can be: 

- A short to another node, the power supply, or 
ground. 

- A damaged IC loading the node. Example 1 in 
Figure 7-6 shows a bad input at U6 causing node 
A to be loaded. 

Another output source is also driving that node. 
Check the enable and control lines of any other 
devices that can drive the node. Example 2 in 
Figure 7-6 shows node A to be loaded because 
both U1 and U5 are attempting to drive the node 
at the same time. U1 is operating as it should but 
the U5 enable-line state is incorrect and U5 is 
also driving the same node. 

Operators should be provided with a procedure for tracing short 
circuits. For example, a milliohmmeter can be used to determine 
the point at which a node is shorted. To do this, attach one lead 
of the milliohmmeter to the faulty node. With the other lead, 
look for low resistance paths. 
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Figure 7-6: Node Loading 
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Section 8 

Glossary 


If you cannot find a term in the glossary, search the index for a 
reference to that term. 


Active Edge 

A signal transition used to initiate action. 

Address Space 

A section of memory reserved for a particular use, such as the 
stack. The term "decoded address space" implies memory 
residing in physically separate chips (selectively enabled by a 
"decoder"), such as a frame buffer, character generator, or the 
control registers inside a peripheral chip. 

Aliasing 

A condition where a component address responds to more than 
one combination of address bus bits. 

Assert 

To cause a signal to change to its logical "true" state. 
Asynchronous 

Not synchronized to the microprocessor or not synchronous to 
any clock signal. 
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Automated Test 

An automated activity that verifies the correct operation of a 
circuit by comparing its output to the expected output. 

Automated Troubleshooting 

An automated process of locating a fault on a UUT. 

Backtracing 

A procedure for locating the source of a fault on a UUT by 
checking logic along a logical path from bad outputs to bad 
inputs until the point where no bad inputs are found. 

Bus 

A group of functionally similar signals. 

Bus Contention 

A situation where two or more bus devices are trying to put 
different data onto the same bus. 

CAD 

An acronym for Computer-Aided Design. CAD systems let the 
user create, manipulate, and store designs on a computer. 

Comment 

Text in a program that is not executed. A comment in a TL/1 
program or a node list must begin with an exclamation point (!). 

Component 

A passive or active part on a UUT. 

Control Line 

A signal that comes out of a microprocessor and is used to 
control the UUT. 

CRC Signature 

CRC is an acronym for Cyclic Redundancy Check. A CRC 
signature is a compression of a long data stream into a 16-bit 
number. 

Cursor 

A symbol on a display (usually a box or an underscore) that 
indicates where a typed character will appear. 





Data Bus 

A set of signal paths on which parallel data is transferred 
between two or more devices. 

Device 

1. Refers to the probe, an I/O module, a reference designator, 
or the pod. 2. Also used with I/O operations to specify a port 
or a disk drive. 

DIP 

An acronym for Dual In-line Package. A DIP has an equal 
number of pins on each of its long sides. See also SIP. 

Directory 

A collection of related sets of data (files, for example) on a disk. 

Drivability 

Testing whether lines can be driven to the appropriate active high 
or active low level. 

Dynamic Coupling 

Data in one memory location is affected by combinations of data 
in other memory locations. 

Edge 

The transition from one voltage level to a different voltage level. 
Exerciser 

See Fault Condition Exerciser. 

External Synchronization 

Synchronizing a node response measurement using signals 
external to the pod. 

Fault 

A defect in a UUT that causes circuitry to operate in a manner 
that is inconsistent with its design. 

Fault Condition 

A recognition by the 9100A/9105A that a fault exists on the 
UUT. 
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Fault Condition Exerciser 

A group of statements that attempts to repetitively reproduce the 
conditions that generate a fault condition. (Sometimes called just 
an "exerciser.") 

Fault Condition Handler 

A group of statements that is executed when a particular fault 
condition occurs. (Sometimes called just a "handler.") 

Fault Condition Raising 

The generation of a fault condition either from detecting a fault 
on a UUT or from using a TL/1 fault statement. 

Feedback Loop 

A circuit in which one or more outputs is routed to the circuit's 
input. 

Forcing Line 

Input to the microprocessor that forces it to a particular known 
state. 

Functional Test 

An activity that verifies the correct operation of a circuit by 
comparing its output to the expected output. 

GFI 

See Guided Fault Isolation. 

GFI Summary 

A record of the components that have been tested by GFI. 
Go/No-Go Test 

A pass/fail test; either a unit passes or it doesn’t. 

Guided Fault Isolation 

An algorithm that uses backtracing to troubleshoot a UUT. 

Handler 

See Fault Condition Handler. 
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Hexadecimal 

Pertaining to the base 16 numbering system. (Often abbreviated 
as "hex.") 

I/O 

An abbreviation for Input/Output. The transfer of data to and 
from devices other than the local memory of the microprocessor 
system. 

I/O Module 

An option for the 9100A/9105A that allows simultaneous 
stimulus or response for multiple points on a UUT. 

Level History 

A character string that represents a record of the logic levels 
measured at a point over a period of time. "1", "X", and "0" 
represent high, invalid, and low states, respectively. 

Library 

A directory that contains a collection of only a particular type of 
file. The 9100A/9105A uses four libraries: a part library, a 
program library, a pod library, and a help library. 

Mask 

A value where each logic "1" represents a bit that is to be acted 
on. 

Monitor 

A 24-line, 80-column video display that connects to the rear 
panel of the 9100A/9105A. 

Node 

A set of points that are all electrically interconnected. 

Node List 

A file containing a description of the interconnection of all pins 
on a UUT. 

Operator 

1. A symbol that acts on one or more values or expressions to 
produce another value. 2. A person who uses the 9100A/ 
9105A for testing or troubleshooting. 
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Operator's Display 

Three-line display on the mainframe of the 9100A/9105A. 

Operator's Interface 

The operator's display and the operator's keypad. 

Operator's Keypad 

The set of keys on the front panel of the base unit of the 
9100A/9105A. 

Overdrive 

To put a logic state on a signal line by applying more power than 
the normal driver for that node. This is how the 9100A/9105A 
injects signals into the UUT. 

Part Description 

A file that describes a component on a UUT. 

Part Library 

A library of part descriptions. 

Pod Library 

A library of pod descriptions, each of which contains a pod 
database and pod-related TL/1 programs. 

Pod Synchronization 

Synchronizing a node response measurement using signals 
generated by the pod to indicate the sampling time. 

Priority Pin 

A pin that the GFI program will test first if a particular node is 
bad. 

Probe 

A hand-held device that can stimulate and measure any single 
point on the UUT. 

Program Library 

A library of programs that can be called by any program in the 
userdisk. 




Programmer's Interface 

The monitor and the programmer's keyboard. 

Programmer's Keyboard 

The keyboard that connects to the side panel of the 9100A. 
Raise 

See Fault Condition Raising. 

Reference Designator 

A one to ten character string naming a component on the UUT. 

Related Input Pin 

An input pin on a component that affects an output pin on that 
same component. 

Response File 

A file containing data generated by executing a specific stimulus 
program to a UUT and recording the responses from its 
execution. 

RUN UUT Test 

A feature that allows the normal operation of a UUT using its 
own program. 

Signature 

See CRC Signature. 

SIP 

An acronym for Single In-line Package. See also DIP. 

Softkey 

A key that has its function determined by software. 

State Machine 

A circuit which produces output signals in response to input 
signals and its own internal state. Typically used to generate a 
sequence of control signals, as in a bus interface. 
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Stimulus Program 

A program that exercises a circuit while the activity on circuit 
nodes are recorded to see if the circuit produces the same 
response as a known-good circuit. 

String 

A group of characters enclosed in double-quote characters (") 
and manipulated as a single entity. 

Synchronous 

Coordinated to the transitions of a clock signal. 

Termination Status 

An indication of whether a UUT passed a test. 

Timeout 

A condition in which an expected event has not occurred within 
the expected time period. 

Toggle 

Change to the complementary logic state. 

Transition Count 

A record of the number of times the logic level at a node changes 
from low to high within a period of time. 

Troubleshooting 

A process of locating the area of a UUT that is causing a fault. 

Userdisk 

1. A diskette containing test programs and information about a 
particular UUT. 2. The current disk drive that is used as a 
source for UUT programs and data. 

UUT 

Unit Under Test. A physical item, i.e., a board or a system to 
be tested. 

UUT Directory 

A set of files that contain information about a particular UUT. 
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Wait State 

A bus cycle which is too short for a slow chip is lengthened by 
the insertion of one or more clock cycles, called wait states. 

Watchdog Timer 

A circuit which produces a signal, typically a reset or high- 
priority interrupt, if a timeout condition is met. For example, an 
excessive number of wait states may trigger a watchdog timer. 

Wildcard 

A symbol that represents any sequence of characters. The 
9100A/9105A uses the asterisk character (*) for this purpose. 

Window 

An area of the monitor reserved for certain information to be 
displayed. 
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Appendix A 

Demo/Trainer UUT 

Reflist 


NAME: REFLIST 

DESCRIPTION: SIZE: 3,555 BYTES 


REF 

PART 

TESTING 

DEVICE 

R72 

RESISTOR 

PROBE 

R73 

RESISTOR 

PROBE 

R4 

RESISTOR 

PROBE 

R7 9 

RESISTOR 

PROBE 

R78 

RESISTOR 

PROBE 

R61 

RESISTOR 

PROBE 

R62 

RESISTOR 

PROBE 

R63 

RESISTOR 

PROBE 

R64 

RESISTOR 

PROBE 

R65 

RESISTOR 

PROBE 

R70 

RESISTOR 

PROBE 

C4 

CAPACITOR 

PROBE 

C5 

CAPACITOR 

PROBE 

C8 

CAPACITOR 

PROBE 

C9 

CAPACITOR 

PROBE 

C13 

CAPACITOR 

PROBE 

C15 

CAPACITOR 

PROBE 

Cl 6 

CAPACITOR 

PROBE 

C17 

CAPACITOR 

PROBE 

U74 

2016 

I/O MODULE 

U85 

2016 

I/O MODULE 

U72 

2674 

I/O MODULE 

U78 

2675 

PROBE 

Ull 

2681 

PROBE 

U77 

27128 

I/O MODULE 

U30 

27256 

I/O MODULE 
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U29 

27256 

I/O MODULE 

U28 

27256 

I/O MODULE 

U27 

27256 

I/O MODULE 

Q1 

TRANSISTOR 

PROBE 

Q2 

TRANSISTOR 

PROBE 

Cl 

CAPACITOR 

PROBE 

R35 

RESISTOR 

PROBE 

R1 

RESISTOR 

PROBE 

R77 

RESISTOR 

PROBE 

R80 

RESISTOR 

PROBE 

R15 

RESISTOR 

PROBE 

R14 

RESISTOR 

PROBE 

R16 

RESISTOR 

PROBE 

R13 

RESISTOR 

PROBE 

R17 

RESISTOR 

PROBE 

R12 

RESISTOR 

PROBE 

R18 

RESISTOR 

PROBE 

Rll 

RESISTOR 

PROBE 

R2 7 

RESISTOR 

PROBE 

R25 

RESISTOR 

PROBE 

R2 4 

RESISTOR 

PROBE 

R2 8 

RESISTOR 

PROBE 

R2 9 

RESISTOR 

PROBE 

R23 

RESISTOR 

PROBE 

R30 

RESISTOR 

PROBE 

R19 

RESISTOR 

PROBE 

R68 

RESISTOR 

PROBE 

R69 

RESISTOR 

PROBE 

R20 

RESISTOR 

PROBE 

R21 

RESISTOR 

PROBE 

R22 

RESISTOR 

PROBE 

R3 4 

RESISTOR 

PROBE 

R33 

RESISTOR 

PROBE 

R3 

RESISTOR 

PROBE 

R5 

RESISTOR 

PROBE 

R6 

RESISTOR 

PROBE 

R7 

RESISTOR 

PROBE 

R8 

RESISTOR 

PROBE 

R32 

RESISTOR 

PROBE 

R31 

RESISTOR 

PROBE 

R2 6 

RESISTOR 

PROBE 

R9 

RESISTOR 

PROBE 

R2 

RESISTOR 

PROBE 

U34 

4164 

I/O MODULE 

U35 

4164 

I/O MODULE 

U36 

4164 

I/O MODULE 

U37 

4164 

I/O MODULE 

U38 

4164 

I/O MODULE 

U39 

4164 

I/O MODULE 

U40 

4164 

I/O MODULE 






U41 

4164 

I/O MODULE 

U48 

4164 

I/O MODULE 

U49 

4164 

I/O MODULE 

U50 

4164 

I/O MODULE 

U51 

4164 

I/O MODULE 

U52 

4164 

I/O MODULE 

U53 

4164 

I/O MODULE 

U54 

4164 

I/O MODULE 

U55 

4164 

I/O MODULE 

R67 

RESISTOR 

PROBE 

C6 

CAPACITOR 

PROBE 

Cl 

CAPACITOR 

PROBE 

R71 

RESISTOR 

PROBE 

RIO 

RESISTOR 

PROBE 

R 66 

RESISTOR 

PROBE 

U14 

80286 

PROBE 

J5 

CONN68 

PROBE 

U1 

82284 

I/O MODULE 

U15 

82288 

I/O MODULE 

U31 

8255 

I/O MODULE 

U58 

7400 

I/O MODULE 

U24 

7400 

I/O MODULE 

U5 

7400 

I/O MODULE 

U64 

7402 

I/O MODULE 

U57 

7404 

I/O MODULE 

019 

7404 

I/O MODULE 

U4 

7408 

I/O MODULE 

U63 

7408 

I/O MODULE 

U56 

7410 

I/O MODULE 

021 

74138 

I/O MODULE 

U8 

74138 

I/O MODULE 

U9 

74138 

I/O MODULE 

U3 

74245 

I/O MODULE 

U23 

74245 

I/O MODULE 

044 

7474 

I/O MODULE 

CR1 

DIODE 

PROBE 

J2 

CONN__RS232 

PROBE 

J3 

CONN_VIDEO 

PROBE 

J6 

CONN_KEYBD 

PROBE 

073 

74157 

I/O MODULE 

083 

74157 

I/O MODULE 

084 

74157 

I/O MODULE 

065 

74257 

I/O MODULE 

066 

74257 

I/O MODULE 

033 

7SEGLED 

PROBE 

047 

7SEGLED 

PROBE 

061 

7400 

I/O MODULE 

070 

7400 

I/O MODULE 

071 

7400 

I/O MODULE 

062 

7404 

I/O MODULE 


A-3 




U59 

74109 

I/O MODULE 

U80 

7410 

PROBE 

U81 

7410 

PROBE 

U7 

74112 

I/O MODULE 

U25 

74112 

PROBE 

U2 6 

74125 

I/O MODULE 

U20 

74148 

I/O MODULE 

U13 

7414 

I/O MODULE 

U43 

74164 

I/O MODULE 

017 

74164 

I/O MODULE 

U75 

74175 

I/O MODULE 

U68 

74244 

I/O MODULE 

U69 

74244 

I/O MODULE 

U32 

74244 

I/O MODULE 

U4 6 

74244 

I/O MODULE 

U6 

7430 

I/O MODULE 

U79 

7430 

I/O MODULE 

U60 

7431 

I/O MODULE 

U45 

7432 

I/O MODULE 

U86 

74373 

I/O MODULE 

087 

74373 

I/O MODULE 

010 

74373 

I/O MODULE 

U2 

74374 

I/O MODULE 

U16 

74374 

I/O MODULE 

U22 

74374 

I/O MODULE 

U76 

74374 

I/O MODULE 

U42 

74390 

I/O MODULE 

U67 

74590 

I/O MODULE 

U12 

MAX232 

PROBE 

J4 

PWRCONN 

PROBE 

U18 

OSCILLATOR 

PROBE 

U82 

74175 

PROBE 

U88 

7486 

PROBE 

Y1 

XTAL 

PROBE 

S4 

KEYSWITCH 

PROBE 

S3 

KEYSWITCH 

PROBE 

S2 

KEYSWITCH 

PROBE 

SI 

KEYSWITCH 

PROBE 

S6 

KEYSWITCH 

PROBE 

DS1 

LED 

PROBE 

Z1 

NETWORKIO 

I/O MODULE 







Appendix B 

Demo/Trainer UUT 
Node List 


NAME: 

NODELIST 

DESCRIPTION: 


U23-11 

U41-2 

U69-17 

U23-12 

U40-2 

U40-14 

U23-13 

U39-2 

U39-14 

U23-14 

U38-2 

U38-14 

U23-15 

U37-2 

U37-14 

U23-16 

U36-2 

U36-14 

U23-17 

U35-2 

U35-14 

U23-18 

U34-2 

U34-14 

U58-8 l 

334-15 

U35-15 

R69-1 

R72-1 

U88-8 

U84-6 

U72-32 


R14-1 

U46-12 


R13-1 

D46-14 


R12-1 

U46-16 


Rll-1 

U46-18 


R18-1 

U4 6-3 


R17-1 

U4 6-5 


R16-1 

U4 6-7 


R15-1 

U46-9 


U32-11 

U31-40 


R27-1 

U32-9 


R25-1 

U32-12 


R24-1 

U32-14 


R23-1 

U32-16 


R19-1 

U32-18 


R30-1 

U32-3 


U32-13 

U31-39 


R28-1 

U32-7 


U32-15 

U31-38 



U30-11 

U28-11 

U41-14 

U69-15 

U30-12 

U28-12 

(J69-13 

U30-13 

U28-13 

U69-11 

U30-15 

U28-15 

U69-8 

U30-16 

U28-16 

U69-6 

U30-17 

U28-17 

U69-4 

U30-18 

U28-18 

U69-2 

U30-19 

U28-19 

U36-15 

U37-15 

U38-15 


SIZE: 16,492 BYTES 

Zl-10 

Zl-9 

Zl-8 

Zl-7 

Zl-6 

Zl-5 

Zl-4 

Zl-3 

U39-15 U40-15 U41-15 


B-1 






R29-1 U32-5 

U32-8 U31-1 

R27-2 U33-7 

R19-2 U33-1 

U2-5 U66-6 021-2 U30-26 U29-26 028-26 U27-26 

084-3 U72-31 

084-10 U72-33 

U16-15 U65-5 084-11 011-4 U72-38 031-8 U30-9 U29-9 \ 

U28-9 U27-9 

Ull-36 Yl-1 C8-1 

011-37 Yl-2 C9-1 

016-19 061-9 U21-4 U62-9 U62-11 

U70-11 U81-5 

U22-9 U61-10 057-13 062-13 

065-1 066-1 060-7 

03-18 048-2 048-14 068-2 010-19 011-21 072-15 031-27 

029-19 027-19 


02-6 066-3 021-1 030-2 029-2 028-2 027-2 

R25-2 033-8 

R24-2 033-10 

R23-2 033-13 

R29-2 033-11 

032-6 031-2 

032-2 031-4 

032-4 031-3 

046-11 031-22 

R12-2 047-13 

R17-2 047-11 

R13-2 047-10 

R14-2 047-8 

R15-2 047-7 

Rll-2 047-1 

058-2 08-14 

061-1 062-12 

061-4 062-10 

043-11 061-12 067-11 067-13 044-1 044-13 059-13 

061-6 068-1 068-19 074-21 

061-3 069-1 069-19 085-21 

070-3 071-2 

070-6 071-4 

070-8 071-5 

056-10 021-15 072-2 

075-5 083-10 072-29 

068-3 074-9 077-6 

068-5 074-10 077-5 

068-14 074-15 077-24 

076-6 078-4 

076-5 078-36 

088-9 078-29 

087-13 077-16 


\ 



B-2 




U87-8 

077-15 



U87-17 

U77-18 


087-7 

077-13 



087-18 

U77-19 


075-2 

U77-10 



075-7 

U77-9 



U75-10 

U77-8 



086-19 

U78-19 



087-14 

U77-17 



087-3 

U77-11 



087-4 

U77-12 



U86-15 

078-17 



U86-16 

078-16 



U86-12 

U78-25 



U86-6 

U78-18 



U69-9 

U8 6“13 

085-13 


069-18 

U85-17 

077-26 


U72-23 

U78-11 



069-12 

U86-8 

085-14 


U80-8 

U81-13 



080-10 

081-10 

082-6 


U80-12 

U81-1 



080-2 

U7 0-5 

071-12 081-4 

D82-15 

U80-4 

U70-9 

U81-11 U82-10 


U80-6 

U81-2 



080-11 

079-11 

082-14 


080-5 

079-4 

062-2 


U80-3 

070-13 

079-5 U81-9 

082-3 073-1 083-1 084-1 062-5 

070-12 

076-11 

U79-3 U8G-11 087-11 U72-16 078-33 

071-13 

07 9-6 

U81-3 082-11 


022-5 

021-6 



U83-9 

074-3 

085-3 


U3-11 

055-2 

055-14 068-17 

010-2 011-28 072-8 031-34 \ 

U29-11 U27- 

11 


032-17 

031-37 



U2-15 

065-6 

073-11 030-24 

029-24 028-24 027-24 

U16-5 

066-5 

083-11 030-5 

029-5 028-5 027-5 

U46-13 

031-23 



U46-8 

U31-21 



U2-9 U65-13 

030-23 029-23 

028-23 027-23 

U27-22 

06-5 045-3 028-22 


034-4 

035-4 

036-4 037-4 

038-4 039-4 040-4 041-4 048-4 \ 

U49-4 

050-4 

051-4 052-4 

053-4 054-4 055-4 064-8 063-8 

U34-5 

035-5 

036-5 065-4 

067-15 037-5 038-5 039-5 040-5 \ 

041-5 

» 048-5 

049-5 050-5 

051-5 052-5 053-5 054-5 055-5 

034-6 

035-6 

036-6 065-9 

067-2 037-6 038-6 039-6 040-6 \ 

041-6 

i 048-6 

049-6 050-6 

051-6 052-6 053-6 054-6 055-6 

034-7 

035-7 

036-7 065-7 

067-1 037-7 038-7 U39-7 040-7 \ 

U41-7 

048-7 

049-7 050-7 

051-7 052-7 053-7 054-7 055-7 

U34-3 

035-3 1 

036-3 037-3 ' 

038-3 039-3 040-3 041-3 048-3 \ 


B-3 







04 9-3 050-3 U51-3 052-3 U53-3 054-3 U26-8 U55-3 

034-12 U35-12 036-12 U65-12 067-3 U37-12 U38-12 U39-12 \ 

040-12 U41-12 U48-12 U49-12 U50-12 U51-12 U52-12 053-12 \ 

054-12 U55-12 

034-11 U35-11 036-11 U66-4 067-4 03.7-11 U38-11 U39-11 \ 

U40-11 U41-11 U48-11 U49-11 U50-11 051-11 U52-11 U53-11 \ 

U54-11 U55-11 

034-10 U35-10 U36-10 U66-7 U67-5 U37-10 U38-10 U39-10 \ 

U40-10 041-10 U48-10 049-10 U50-10 051-10 052-10 U53-10 \ 

U54-10 U55-10 

034-13 U35-13 U36-13 U66-9 067-6 \ 

U37-13 038-13 U39-13 U40-13 U41-13 U48-13 049-13 U50-13 

051-13 052-13 053-13 054-13 055-13 

058-11 048-15 049-15 050-15 051-15 052-15 053-15 054-15 \ 

055-15 
06-2 08-11 
06-3 08-10 


05-10 

011-9 

072-3 

031-36 

015-11 


057-2 

05-13 





083-12 

074-4 

085-4 




06-11 

081-8 





016-2 

066-11 

083-5 

030-4 

029-4 

028-4 027-4 

043-9 

056-12 





02-12 

065-10 

073-5 

030-21 

029-21 

028-21 027-21 

056-1 

044-9 

064-12 




034-9 

035-9 

036-9 

066-12 

067-7 

037-9 038-9 039- 


041-9 048-9 049-9 050-9 051-9 052-9 053-9 054-9 055-9 

056-9 021-14 011-39 

046-15 031-24 

046-17 031-25 

076-15 078-38 

075-15 077-7 

069-14 086-7 085-15 

045-1 045-4 056-3 079-2 057-1 015-8 

045-5 09-9 030-20 029-20 

02-16 065-3 073-14 030-25 029-25 028-25 027-25 
02-19 066-14 083-2 030-3 029-3 028-3 027-3 

046-6 031-20 

046-4 031-19 

046-2 031-18 

016-6 066-2 083-14 030-6 029-6 028-6 027-6 

03-14 052-2 052-14 068-11 010-9 011-19 072-11 031-31 \ 

029-15 027-15 

03-13 053-2 053-14 068-13 010-6 011-27 072-10 031-32 \ 

029-13 027-13 

088-4 078-28 

082-1 013-10 

03-15 051-2 051-14 068-8 010-12 011-26 072-12 031-30 \ 

029-16 027-16 

022-4 J5-66 014-66 





B-4 







022-14 J5-13 014-13 

U22-18 J5-15 014-15 

02-4 J5-17 014-17 

022-13 J5-12 U14-12 

U22-17 J5-14 U14-14 

U14-52 C4-1 

J5-52 C13-1 

U16-8 J5-27 014-27 

016-7 J5-26 U14-26 

016-13 J5-28 014-28 

01-10 017-8 044-3 044-11 059-4 J5-31 \ 

07-1 013-1 014-31 015-2 

016-14 J5-32 014-32 

016-18 J5-34 014-34 

Rl-2 01-4 019-1 J5-63 04-12 014-63 015-1 

023-2 J5-51 014-51 

023-3 J5-49 014-49 

03-2 J5-50 014-50 

03-6 J5-42 014-42 

023-4 J5-47 014-47 

023-5 J5-45 014-45 

023-6 J5-43 014-43 

023-8 J5-39 014-39 

02-11 016-11 022-11 07-2 015-5 

056-5 011-10 072-1 031-5 015-12 

016-16 065-2 084-14 011-2 072-37 U31-9 030-10 029-10 \ 

028-10 027-10 

023-9 J5-37 014-37 

026-1 013-4 013-13 014-64 

03-5 J5-44 014-44 

022-8 J5-1 014-1 

023-7 J5-41 014-41 

03-9 J5-36 014-36 

J5-64 013-12 

03-8 J5-38 014-38 

03-7 J5-40 014-40 

02-8 J5-19 014-19 

02-2 066-10 021-3 030-27 029-27 028-27 027-27 

03-3 J5-48 014-48 

02-18 J5-23 014-23 

03-4 J5-46 U14-46 

084-12 074-8 085-8 

084-9 074-7 085-7 

01-16 J5-4 014-4 015-3 

R26-1 013-3 

016-12 065-11 084-5 011-6 072-39 030-8 029-8 028-8 \ 

027-8 

06-4 045-6 030-22 029-22 

021-13 04-10 031-6 

U3-12 054-2 054-14 068-15 010-5 011-18 072-9 031-33 \ 


B-5 





U29-12 027-12 

R5-1 Sl-1 U31-14 
R6-1 S2-1 U31-15 

R7-1 S3-1 U31-16 

R8-1 S4-1 031-17 

U56-8 05-5 

U68-7 U74-11 U77-4 

U71-3 082—4 

U16-9 065-14 U84-2 011-7 030-7 029-7 028-7 027-7 

061-13 058-6 059-2 059-3 060-1 063-9 

058-12 062-8 

056-13 059-12 013-2 

065-15 066-15 044-5 044-12 

02-7 J5-18 014-18 

01-12 019-3 J5-29 011-38 013-11 031-35 014-29 

01-15 J5-5 014-5 015-19 

084-4 074-5 085-5 

084-13 072-34 

088-13 072-18 

088-1 072-19 

073-13 072-26 

073-10 072-25 

072-7 078-8 

U83-7 074-2 085-2 

083-4 074-1 085-1 

06-8 05-1 

013-5 013-8 

R33-1 020-4 

076-9 078-37 

R20-1 R21-1 R22-1 012-2 

019-2 07-3 

043-8 042-3 

086-9 078-14 

017-9 04-11 05-2 

07-5 08-4 

019-4 07-15 

045-9 056-6 

084-7 074-6 085-6 

020-6 010-7 

076-19 063-4 U63-13 

U20-2 011-24 R3-1 

U76-16 063-5 078-2 

069-7 086-14 085-11 

08-13 062-1 

045-10 05-8 

075-9 062-4 

063-6 078-39 

076-2 063-12 078-5 

080-9 080-13 070-1 070-4 070-10 082-2 

081-12 082-12 





B-6 











068-16 

U74-16 U77-21 

U75-13 

U83-3 

072-27 

U68-12 

074-14 

[ 077-25 

057-6 

05-12 


069-5 

U86-17 

085-10 

U69-16 

085-16 077-2 

J2-2 

012-7 


J2-3 

U12-13 

R21-2 

Ul-13 

042-4 


U25-1 

025-9 

078-32 

U80-1 

061-2 

061-5 070- 

071-9 

079-8 


U60-2 

060-5 

060-15 

020-9 

010-3 


020-7 

010-4 


Ull-13 

012-10 

R34-1 

025-15 

U63-11 

078-6 


U76-12 

078-3 


068-18 

074-17 

077-23 

U69-3 

086-18 

085-9 

075-4 

083-13 

072-30 

U75-12 

083-6 

072-28 

073-6 

072-24 

078-13 

U4-5 

05-6 


U4-1 

05-11 


Dll-35 

013-6 


Dll-5 

012-9 


060-14 

019-5 


U44-2 

064-13 


Dll-14 

012-11 


U4-2 l 

05-9 015-13 

U57-4 

09-5 


U57-9 

015-16 


U22-12 

057-3 

08-5 

U20-12 

011-15 

R2-1 

U3-17 

04 9-2 

049-14 068- 

029- 

18 027- 

18 

U68-9 

074-13 

077-3 

U62-3 

072-17 

078-12 

U22-6 

021-5 

08-6 09-6 

U12-1 C15-1 


J6-2 

011-33 

013-9 R31- 

U16-3 

J5-24 

014-24 

016-17 

J5-33 

014-33 

R80-1 

J5-61 

014-61 

R77-1 

J5-59 

U14-59 

U20-15 

J5-57 

014-57 

R78-2 

J5-54 

014-54 

U16-4 

J5-25 

014-25 


U82-7 


U10-16 


C7-1 


Dll-25 072-14 


U31-28 


\ 


B-7 





Ul-5 U25-5 

J5-16 U14-16 U2-3 

U3-1 U23-1 U15-17 

Ul-2 U4-6 

U26-2 U14-65 

U45-8 U24-5 U4-13 

U24-4 U19-6 

U26-9 U56-4 U15-9 

Ul-11 R10-2 R9-2 C5-1 CR1-2 

R22-2 J2-20 

J2-5 U12-8 R20-2 

J2-4 U12-14 

Ull-17 J6-3 

U73-7 U74-19 U85-19 

U62-6 U74-20 U85-20 

U73-12 U74-23 U85-23 

U73-9 U74-22 U85-22 

Dll-11 U12-12 

U12-3 C15-2 

U12-4 C17-1 

U80-7 

RIO-1 S6-1 
U3-19 U23-19 U57-8 

U22-16 U8-2 U9-2 

U22-15 U8-3 U9-3 

U17-11 U5-4 

U4-3 U4-9 U10-1 U10-11 

U3-16 U50-2 U50-14 U68-6 U10-15 Ull-20 U72-13 

U31-29 U29-17 U27-17 

U64-9 U24-6 

U6-6 U59-6 

U56-11 U4~8 

U61-8 U79-12 

U61-11 U59-11 

U57-5 U8-12 

U56-2 U67-14 U44-6 

U45-2 U9-7 U28-20 U27-20 

U58-1 U8-15 

U44-8 U63-10 

U57-12 U58-10 

U58-5 U59-9 U64-11 

U58-9 U58-13 U64-10 

U22-19 U66-13 U8-1 U9-1 

U22-7 J5-67 U14-67 U15-18 

U2-13 J5-20 U14-20 

U2-14 J5-21 U14-21 

U2-17 J5-22 U14-22 

R7 9-2 J5-53 U14-53 

U42-1 U42-7 

U76-17 U87-16 



B-8 








U76-13 

U87-12 

U76-8 

U87-9 

U4-4 

U5-3 

U12-6 

Cl 6-2 

U59-10 

U59-14 

U76-4 

U87-5 

U88-11 

J3-9 

U88-3 

J3-8 

R73-2 

R71-2 J3-7 

U12-5 

C17-2 

U18-8 

U82-9 U25-13 

U71-10 

U71-11 

U58-3 

U58-4 

R32-1 

J6-1 C6-1 

U76-14 

U87-15 

U76-3 

U87-2 

U71-6 

U82-5 

U71-8 

U82-13 

R67-2 

Q2-1 Ql-2 

U76-7 

U87-6 

R68-1 

R70-1 U88-6 

R28-2 

U33-2 

R30-2 

U33-6 

R16-2 

U47-2 

R18-2 

U47-6 

U71-1 

U81-6 

R7 0-2 

R72-2 R66-2 

R71-1 

Ql“l 

R61-1 

R62-1 R63-1 

U76-18 

U87-19 

J2-7 

R4-1 

R35-1 

DS1-2 


Q2-2 

R64-1 R65-1 U78-1 


! GROUND NODES 

R73-1 Ul-3 Ul-9 U2-1 U2-10 U3-10 U6-7 U16-1 \ 

U16-10 U22-1 U22-10 U23-10 U26-7 U26-10 U34-16 \ 

U35-16 U36-16 U37-16 U38-16 U39-16 U40-16 041-16 U43-7 \ 

U45-7 U48-16 U49-16 U50-16 U51-16 U52-16 U53-16 \ 

U54-16 U55-16 U56-7 061-7 U65-8 U66-8 U67-8 U67-12 \ 

U68-10 U69-10 U70-7 U71-7 U75-8 U76-1 U76-10 \ 

U79-7 U81-7 U86-1 U86-3 U86-4 U86-10 U87-1 U87-10 \ 

U88-2 U88-5 U88-7 U88-10 U17-7 \ 

U42-2 U42-8 U42-12 U42-14 U42-15 U57-7 U58-7 U44-7 \ 

U59-8 U82-8 U60-8 U73-8 U73-15 U83-8 U83-15 U84-8 \ 

U84-15 U64-7 U24-7 U19-7 U20-5 U20-8 U21-8 \ 

J5-9 J5-35 J5-60 U4-7 U5-7 \ 

R4-2 U7-8 U8-8 U9-4 U9-8 U10-8 \ 

U10-10 U10-13 U10-17 U10-18 Ull-22 J3-1 J3-6 \ 

U12-15 C16-1 U13-7 J4-6 J4-7 J4-8 J4-9 S4-2 S3-2 \ 
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S2-2 Sl-2 S6-2 U25-8 C5-2 U32-1 032-10 U32-19 046-1 \ 

046-10 046-19 Q2-3 062-7 063-7 074-12 074-18 J6-4 C4-2 C13-2 \ 

072-20 085-12 085-18 077-14 077-20 077-22 078-9 \ 

078-10 078-15 078-20 078-21 078-22 078-23 078-24 078-31 \ 

031-7 030-14 029-14 028-14 027-14 014-9 014-35 014-60 \ 

015-6 015-7 015-10 Cl-2 C6-2 C7-2 \ 

018-7 R35-2 R77-2 R80-2 C8-2 C9-2 Zl-1 



! POWER NODES 


018-1 DS1-1 Rl-1 R34-2 R33-2 R3-2 033-3 033-14 R5-2 R6-2 \ 

R7-2 R8-2 080-14 R32-2 R31-2 R68-2 R69-2 R67-1 \ 

R61-2 R62-2 R63-2 R64-2 R65-2 01-1 01-6 01-17 \ 

Ul-18 02-20 03-20 06-1 06-12 06-14 016-20 \ 

022-3 022-20 023-20 026-14 034-8 U35-8 036-8 037-8 \ 

038-8 039-8 040-8 041-8 043-1 043-2 043-14 \ 

045-14 U47-3 047-14 048-8 049-8 050-8 051-8 052-8 \ 

U53-8 054-8 055-8 056-14 U61-14 065-16 066-16 \ 

067-10 067-16 068-20 069-20 070-14 071-14 075-1 075-16 \ 

076-20 079-1 079-14 081-14 086-20 U87-20 088-12 \ 

088-14 017-1 017-2 017-14 R66-1 R79-1 R78-1 \ 

R26-2 R9-1 J5-62 014-62 042-16 057-14 \ 

058-14 044-4 U44-10 U44-14 U59-1 059-5 059-15 \ 

059-16 082-16 060-6 060-16 073-16 083-16 084-16 064-14 \ 

024-14 019-14 020-1 020-3 020-10 020-11 020-13 \ 

020-16 021-16 J5-30 04-14 05-14 07-4 \ 

07-16 08-16 09-16 010-14 010-20 011-44 R2-2 012-16 \ 

013-14 J4-10 J4-11 Cl-1 J4-12 J4-13 025-2 \ 

025-3 025-4 025-10 025-11 025-12 025-14 025-16 CR1-1 \ 

032-20 046-20 Ql-3 062-14 063-14 074-24 \ 

J6-5 072-36 072-40 085-24 077-1 077-27 077-28 078-7 \ 

078-30 078-34 078-35 078-40 031-26 030-1 030-28 \ 

029-1 029-28 028-1 028-28 027-1 027-28 014-30 015-14 \ 

015-15 015-20 



! ONOSED OOTPOTS 


02 6-3 
073-4 
075-3 
075-6 
075-11 
075-14 
086-2 
086-5 
015-4 
059-7 
042-5 
042-6 
042-13 
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U42-11 

042-10 

U42-9 

043-3 

U43-4 

U43-5 

043-6 

043-10 

043-12 

043-13 

067-9 

031-13 

031-12 

031-11 

031-10 

011-8 

011-40 

011-3 

011-43 

011-42 

011-41 

011-32 

011-31 

011-30 

011-16 

011-29 

U8-9 

08-7 

09-15 

09-14 

09-13 

09-12 

09-11 

09-10 

021-12 

021-11 

021-10 

021-9 

021-7 

025-7 

U25-6 

U20-14 

U17-3 

017-4 

017-5 

017-6 

017-10 

017-12 

017-13 


... 







*masters 


! PROCESSOR ADDRESS LINES 

U14-34 

U14-33 

014-32 

U14-28 

U14-27 

U14-26 

U14-25 

U14-24 

U14-23 

U14-22 

U14-21 

U14-20 

U14-19 

014-18 

U14-17 

014-16 

U14-15 

014-14 

014-13 

014-12 

! BUFFERED ADDRESS LINES 
016-19 
016-16 
016-15 
U16-12 
U16-9 
U16-6 
U16-5 
U16-2 

U2-19 

02-16 

U2-15 

U2-12 

U2-9 

U2-6 

U2-5 

U2-2 

U22-19 

022-16 

022-15 

U22-12 
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U22-9 

U22-6 

U22-5 

! PROCESSOR DATA LINES 

U14-51 

U14-49 

U14-47 

UI4-45 

U14-43 

U14-41 

U14-39 

U14-37 

U14-50 

U14-48 

U14-46 

U14-44 

U14-42 

U14-40 

U14-38 

U14-36 

! BUFFERED DATA LINES 

U23-18 

U23-17 

U23-16 

U23-15 

U23-14 

U23-13 

U23-12 

U23-11 

U3-18 

U3-17 

U3-16 

U3-15 

U3-14 

U3-13 

U3-12 

U3-11 
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Appendix C 

Subprograms for 
Functional Test and Stimulus 

Programs 


The following programs are included in this appendix: 
abort test 
checkjoop 
checkjneas 
recover 
tst conten 
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program abort_test(ref) 

11 ! it j i ! m ! M ! ! ! ! ! ! m j ! j i i it t t t i i i 11 j m t it i m t M t t i 11 m ! ! i i ! 11! m it t t ! ! ! 

! FUNCTIONAL TEST of the Microprocessor Bus. 

t 

! This program is called by many of the test programs after the test 
! program has found a failing circuit. This program highlights the part 
! with the FAILED test attribute, changes all parts with a TESTING test 
! atribute to UNTESTED, and then checks to see if gfi has enough test 
! results to make an accusation. If an accusation exists then the 
! accusation is displayed. Otherwise a gfi hint is generated for the 
! part and the test programs are terminated so that GFI can begin 
’ troubleshooting. 

t 

! TEST PROGRAMS CALLED: 

! none 

i 

! GRAPHICS PROGRAMS CALLED: 

! fail (part_number) Highlight part to be failed 

t 

!!!!!!! I !!!!!!!!!!!!!!! I! !!!!!!!!!!!!!!!!!!!!!!!!!111!!!!!!! 11!!!!!!! !! ! 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!! !!!!!!!! I !!!!!!! !! ! ! ! !!!!!!!!!!!! ! 
! Main Declarations 

1 I!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 



declare 

string ref 

global numeric t2o 

global string array [1:107] part 

global numeric array [1:107] partatrb 


! The ref-pin of the failed part 
! Buffered I/O on /term2. 

1 Part shape and positions 
! Attribute number of part 


! Next three items relate to Test window displayed by disply_pcb{). 


global string testwindl = M \lB[12;65f\lB[0m\lB[lm" 
global string testwind2 = H \1B[13;65f\lB[0m\lB[lm" 
global string undrtest = M \1B[15;66f\lB[0m" 
end declare 


Place text in line 2 
Place text in line 3 
Place text in line 5 
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I Highlight Failed Part. 


n = instr(ref, 

if n = 0 then n - len(ref) + 1 
ic_num = (val(mid(ref, 2, n-2),16)) 

! convert decimal ic_num to hex 

declOO - ic_num / $100 

declO = (icjnum - declOO * $100) / $10 

decl = (ic_num - declOO * $100 - declO * $10) 

hex_ic_num = declOO * 100 + declO * 10 + decl 

fail(hex_ic_num) 

I Change all parts with a TESTING attribute to an UNTESTED attribute and 
! display GFI TROUBLESHOOTING in the test window. 

for i = 1 to 107 

if partatrb[i] = 2 then untested(i) 
next 

print on t2o ,testwindl," GFI ",testwind2,"TROUBLESHOOTING" 

print on t2o ,undrtest," " 

! If GFI has an accusation then display the accusation otherwise generate 
! GFI Hints. 

accusation = gfi accuse 
if accusation = "" then 
gfi hint ref 

fault 'gfi hints generated' ' please run gfi' 
else 

fault 1 ' '' accusation 
end if 


end program 



program check_loop 

t jt m j 11 t ! i i m i n i!!! I!!!!!!!!!!! I !!!!!!! I!!!!!!!!!!!!!!!! I!!!! !!!!!! II! 
! This program checks the DEMO/TRAINER UUT Loopback switches. If the 
! loopback switches are not closed then a prompt is generated to close 
! the loopback switches. Otherwise no prompt is generated. 

!!!!!J!!!!!!! I!!!!!!!!!!!!!!!!!!!! I!!!!!!!!!!!!!!!!!!!!!!! !I !!!!!!!!!!!! 

function pmpt_lpbk 
declare 

string q 
end declare 

print "Close SW4-4, SW4-5 and SW6-4 for loopback" 
print "Press \lB[7m ENTER \lB[0m key to continue " 
input q \ print 
end function 

execute rs232_init() 

write addr $2006, data $AA 
wait time $200 

if ((read addr $2002) and $F) <> $D then 
execute pmpt_lpbk() 
return 
end if 

write addr $201E, data $FF 
write addr $2016, data $BB 
wait time $200 

if (read addr $2016) <> $BB then 
execute pmpt_lpbk() 
return 
end if 

write addr $201C, data $FF 

if ((read addr $201A) and 2) <> 0 then 
execute pmpt_lpbk {) 
return 
end if 

end program 
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program check_meas(dev, start, stop, clock, enable) 

!!!!!!!! 11!!!!!!!!!!!!! I!!!!!!!! I!!! I!!!!! I!!!!!!!!!!!! !I!! I ! I!!!!! I! I! ! 
! Check status of External START, STOP, CLOCK, ENABLE lines, 

! Return 1 if measurement is complete, display prompt to fix 
! the external lines, wait for ENTER key, and return 0 if the 
l measurement times out. 


I I I I I I I I 1 1 1 1 1 1 I 1 I I I I I 1 

II 111 It t II I1I1II1111 It 

Minimtm 

t it t l It i t i f i t 

i i t r i i i i t r i i i t t r i i 

t I I I t I I I I I t I I I I I I 1 

! ! ! ! ! I I I ! ! I ! ! 

t t i i i i i t t t t t t 

! ! ! 

! Main Declarations 

t t i i 1111 111 111 i t i 1111 t 

1 ! t t t 1 II 1 1 1 1 t 1 

t t 1 It I 1 t M t T M t t II 

f i i i t i i t i i i t t t 

I t ; 


declare string dev 
declare string start 
declare string stop 
declare string clock 
declare string enable 

m it t ti m it t;i11111t ttit it t j 111t t t i t 11 j i | tt t 11 j i j ; it i »11 M m t t t i j i j i i r t 

Main part of program 

!!IJ!!!!!!!!!!!!!!!!!!I!!!!!!!!!!!!!!! I!!!!!!!!!!!!!!! 1 T M I!!!!!!!!!!! ! 


times = 0 

loop while checkstatus(dev) <> $F and times < 100 
times = times + 1 
end loop 

I If START fails then STOP, ENABLE and CLOCK will also fail. 

! If ENABLE fails then CLOCK will also fail. 

! Diagnose cause of failure and only display START if START fails. 
! Do not display CLOCK when ENABLE line fails. 

if times < 100 then 
return (1) 
else 

tl = open device "/terml", mode "unbuffered" 

I turn autolinefeed off and clear screen 


print "\1B[2J\1B[201» 

n = checkstatus(dev) \ str = "" \ line = "" 
if (n and 4) =0 then 
line = line + "START " 
str = str + " START to " + start + "," 
else 

if (n and 8) =0 and stop <> "*" then 
line = line + "STOP, " 
str = str + " STOP to " + stop + "," 
end if 

if (n and 2) =0 and enable <> "*" then 
line = line + "ENABLE " 
str = str + " ENABLE to " + enable + 
else if (n and 1) = 0 then 
line - line + "CLOCK M 
str = str + " CLOCK to " + clock + "," 
end if 
end if 

print "\lB[l;lf", "External line(s) ", line, "failed." 
print "\lB[2;lf", "Connect", str, "\lB[3;lf" 

print "Press \lB[7mENTER \lB[0m to REPEAT, \lB[7mNO \lB[0m to CONTINUE" 


Wait for ENTER key to be pressed. 
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input on tl , str 
print "\1B[20h\lB[2 J" 
close channel tl 
if str = "\7F" then 
return(1) 
else 

return (0) 
end if 
end if 
end program 
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program recover 



I 1 I 1 1 1 1 1 1 1 I I I I ! I M t M t t t I I M ! ! t M I t M t I I ! I I M t M 1 I M J I ! t ! I M ! I I t t t t t I M 

This program recovers sync between the 82288 Bus Controller and the 
80286 pod. 

Some of the stimulus programs disable ready before performing stimulus 
which can cause the 80286 bus controller to get out of sync with the 
pod. The recover() program is executed to resynchronize the bus 
controller and the pod. 

TEST PROGRAMS CALLED: 

(none) 

GRAPHICS PROGRAMS CALLED: 

(none) 

Global Variables Modified: 

recover_times Reset to Zero 

I I I I I I I t t I I M M I 1 t t t I t t t t t t t t I I t I t t t t t t t t t M t t I t I I t I t t t t t 1 I t t I t t t t t t t t I 


!!!!!!!!!!!!!!!! I!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! I!!!!! I!!!! 
Main Declarations 

t t t t t t t t t t t t t t I I M I t t t t t t t t t I t I I I t t t t t I t ! ft t t t t 1 t t t t t t t t t t t t t t t t t t t t t I 


declare global numeric recover_times I Count of executing recover(). 

iit t t t t t t t t t t t t t t t t t 11t jij t t t t t t t j j it t t t t t 111 t t t t 11 m t t t t 11 t j t j t t t t t t t t t 
Main part of STIMULUS PROGRAM ! 

t t t t t t t t t t t t t 1 t t t t t t t t I I t t t t I t t t t 1 I t t t t I t t I t 1 I t t t t t t I I t t t t t t t t t t I 1 t t t ! t 1 


recover_times = recover_times + 1 
if recover_times <« 1 then 

podsetup 'enable -ready' "off" ! POD is out of sync with 

setspace(getspace("memory","word")) ! the 82288 bus controller 

read addr 0 ! Read in memory space then 

write addr 0, data 0 I Write in memory space to 

podsetup 'enable -ready' "on" ! synchronize 82288 and POD. 

else 

podsetup 'enable -ready* "off" 

print "Please press the \!B[7mUUT RESET KEY \lB[0m" 

loop until (readstatus() and $10) <> 0 l wait for RESET active, 
end loop 

podsetup 'enable -ready' "on" 

loop until (readstatus() and $10) = 0 ! wait for RESET inactive, 

end loop 
print "\1B[2J" 
end if 
end program 
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program tst_conten (addr, data_bits) 


iiii m iitit!!1tt m iiiiiiit!11!ii! i t j 111 ! m i m » 11 i ij t j t tt i tt t i it it i t t t m 
TEST to isolate DATA BUS CONTENTION to the failing part. 

This program attempts to determine the cause of Data Bus contention by 
testing the enable lines of all the devices on the Data Bus. This 
program performs several steps. First each device on the data bus is 
accessed and determined to be accessible or inaccessible. The 
variable bad_dev is a mask that records which devices failed. 

Many times when Data Bus contention exists, the device that has the 
bad enable lines can be accessed and the rest of the devices cannot be 
accessed. This program checks the mask to see if all except one 
device is bad and then tests the enable lines on the device that 
appeared good. 

If all devices are bad or more than one device is good then this test 
checks the enable lines of all the devices on the Data Bus by brute 
force. 

TEST PROGRAMS CALLED: 

abort_test (ref-pin) If gfi has an accusation 

display the accusation else 
create a gfi hint for the 
ref-pin and terminate the test 
program (GFI begins trouble¬ 
shooting) . 

FUNCTIONS CALLED: 

testic (refname, pinl, pin2) This function performs a gfi 

test on refname. Then the pins 
pinl and pin2 (which are the 
enable lines) are checked to 
see if they are bad. If so 
abort_test is called and GFI is 
started on the failing enable 
line. Otherwise all test info 
about the part is discarded 
using the gfi clear command. 

I 111111 1111111!!! 1111111111 t j 1111 1111 it 111111! j 111111 111! i m 111111 11111 


j 1111 j j j 11111 j j i! 

Declarations 

M t I 1 I I I 11 tt I 11 I I 


111111 111 


I Main 
mm 


I I I M t I T I I I I T I I 


declare 

numeric addr 
numeric data_bits 
numeric bad_dev = 0 
numeric array [0:$15] ram_ic 
global string contention__checked 
end declare 


! Address where failure occured. 
! Mask of failing data bits. 

! Mask to record failing devices 
I Convert RAM bit to part number 
{ Record that this test ran. 


11 j j j j j I j I I I I ; I I! I! 11 I j I I I I I 1111 j j I j I j 111 I I I I 11 111 I I I I 1111 I I I I I I 111 111 I I 

I Functions 

I I I I I I it 111111 it 11 it t I 1111 it 11 tt 11 111 j 11 j 11111 j i j j i j j j 111111 111 j 111 j 111 j 


function testic (ref, pin_a, pin_b) 
declare numeric ref 
declare numeric pin_a 
declare numeric pin_b 
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I convert decimal ref to hex 


declOO = ref / 100 
declO = (ref - declOO * 100) / 10 
decl = (ref - declOO * 100 - declO * 10) 

href = declOO * $100 + declO * $10 + decl 

ref_a = "U" + str(href,16) + + str(pin_a, 16) 

ref_b = "U" + str(href,16) + + str(pin_b,16) 

if gfi test ref_a fails then 

if (gfi status ref_a) - "bad" then 
abort_test(ref_a) 
else 

if (gfi status ref_b) = "untested" then gfi test ref_b 
if (gfi status ref_b) = "bad" then 
abort_test(ref_b) 
end if 
end if 

gfi clear ! Only looking at Enable Lines, Clear Other Info, 

end if 

end function 



ram_ic[0] 

= 55 

\ 

ram_ic[l] 

= 54 

! RAMs 

U55, 

U54 

ram_ic[2] 

= 53 

\ 

ram_ic[3] 

= 52 

! RAMs 

U53, 

U52 

ram_ic[4] 

= 51 

\ 

ram_ic[5] 

= 50 

! RAMs 

U51, 

U50 

ram__ic[6] 

= 49 

\ 

ram__ic[7] 

= 48 

! RAMs 

U49, 

U48 

ramjLc[8] 

= 41 

\ 

ram_ic[9] 

- 40 

! RAMs 

U41, 

U40 

ram_ic[10] 

= 39 

\ 

ram_ic[ll] 

« 38 

l RAMs 

U39, 

U38 

ram_ic (123 

- 37 

\ 

ram_ic[13] 

= 36 

I RAMs 

U37, 

U36 

ram_ic(14j 

= 35 

\ 

ram_ic[15] 

= 34 

! RAMs 

U35, 

U34 


if contention_cheeked <> "yes" then 
contention_checked = "yes" 
podsetup 'report intr' "off" 
podsetup 'enable ~ready' "on" 
print "\nl\nlTESTING BUS CONTENTION" 



! Read from each device on the bus and record if each device reads correctly. 

! Then check and see if all components are bad except one. If so then check 
! that component's enable lines. 

! Otherwise brute force check all enable lines on all components connected to 
I the bus. 

! ROMO and ROM1 

setspace( getspace("memory", "word")) 

if (read addr $E002A) <> 0 then bad_dev = bad_dev or 1 

if (read addr $F0022) <> 0 then bad_dev = bad_dev or 2 

! Dynamic RAM 

write addr $1000, data $FFFF 

if (read addr $1000) <> $FFFF then bad_dev = bad_dev or 4 
write addr $1000, data 0 

if (read addr $1000) <> 0 then bad_dev = bad_dev or 4 
! PIA registers 
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execute pia_init () 

if (read addr $4002) <> $FF then bad_dev = bad_dev or 8 
write addr $4002, data 0 

if (read addr $4002) <> 0 then bad_dev * bad_dev or 8 


! DUART registers 


execute rs232_init () 
if (read addr $200A) 
if (read addr $201A) 
if (read addr $2012) 


<> $11 then bad_dev = bad_dev or $10 
<> $FF then bad_dev = bad_dev or $10 
<> $C then bad dev = bad dev or $10 


! Video Controller registers 
execute rs232_init () 

if (read addr 8) <> $FF then bad_dev = bad dev or $20 
if (read addr $A) <> 0 then bad_dev = bad_dev or $20 


! If only one device is good, CLIP and check enable lines on that device. 

if bad_dev <> 0 and bad_dev <> $3F then 
! CLIP and Check Enable lines on ROMs 
if bad_dev - $7E then 

if (data_bits and $FF) <> 0 then 
testic(29, $20, $22) 
end if 

if (data_bits and $FF00) <> 0 then 
testic(30, $20, $22) 
end if 

else if bad_dev = $7D then 

if (data_bits and $FF) <> 0 then 
testic(27, $20, $22) 
end if 

if (data_bits and $FF00) <> 0 then 
testic(28, $20, $22) 
end if 

else if bad_dev = $7B then 

testic (ram_ic[msb(data_bits) ], $15, 4) ! Check RAM. 
else if bad_dev = $77 then 

testic (31, 6, 6) I Check PIA. 

else if badjdev = $2F then 

testic (11, $39, 9) ! Check DUART. 

else if bad_dev = $1F then 

testic (72, 2, 3) ! Check Video Controller 

end if 
end if 


! Low data bits are bad 
! Check low byte ROMO. 

! High data bits are bad 
! Check high byte ROMO. 


! Low data bits are bad 
! Check low byte ROMO. 

! High data bits are bad 
! Check high byte ROMO. 


! BRUTE FORCE check enable lines of all devices on bus. 


if (data bits and $FF) <> 0 

then 

! Low data bits are bad 

testic (27, $20, $22) 


! Check low byte ROMO. 

testic(29, $20, $22) 
end if 

if (data bits and $FF00) <> 

0 then 

! High data bits are bad 

testic(28, $20, $22) 


! Check high byte ROMO. 

testic(30, $20, $22) 
end if 

testic (ram ic[msb(data bits)], $15, 4) 

! Check RAM. 

testic (31, 6, 6) 


! Check PIA. 

testic (11, $39, 9) 


! Check DUART. 

testic (72, 2, 3) 


! Check Video Controller 





c-io 




! Check Interrupt Buffer 


testic (10, $11, 1) 
if bad_dev = $3F then 

if (data_bits and $FF) <> 0 then 

if gfi test "U3-1" fails then abort_test("U3-1") 
end if 

if (data_bits and $FFOO) <> 0 then 

if gfi test "U23-1 M fails then abort_test( M U23-1") 
end if 
end if 

print "BUS CONTENTION TEST PASSES" 
end if 
end program 
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Address space, 4-14, 8-1 
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Bus Buffer functional block, 4-243 
example, 4-250 
keystroke functional test, 4-251 
programmed functional test, 4-262 
stimulus programs and response files, 4-263 
summary page, 4-272 
testing and troubleshooting, 4-243 

CAD, 8-2 
Calibration, 7-8 

CAS, See Column Address Strobe 
CAS_STIM stimulus program, 4-88, 4-92 
CAS_STIM response file, 4-94 
Character generator, 4-233 
Clearance, 4-3 
clip command, 3-19 
Clip module, 2-10, 3-19 
Clip module name, 3-19 
Clock and Reset functional block, 4-291 
example, 4-293 

keystroke functional test, 4-294 
programmed functional test, 4-300 
stimulus programs and response files, 4-301 
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Clock and Reset functional block, (continued) 
summary page, 4-312 
testing and troubleshooting, 4-291 
Clock signal, 7-5, 7-7 

Clocked level history, 2-7, 2-9, 2-10, 4-246 

Color look-up table, 4-177 

Column Address Strobe (CAS), 4-75 

Comment, 8-2 

Component, 8-2 

Component extraction tool, 4-3 

Connectors, 4-250 

Control lines, 4-247, 8-2 

Coprocessor cycles, 4-9 

Coupling fault, 4-61 

CRC signature, 2-10,3-19, 4-245, 7-5, 8-2 
Crystal oscillator, 4-154, 4-291 
CTRL_OUT1 stimulus program, 3-16, 4-28 
used in other chapters, 4-263 
CTRL_OUT1 response file, 4-30 
CTRL_OUT2 stimulus program, 3-16, 4-266 
CTRL_OUT2 response file, 4-268 
CTRL_OUT3 stimulus program, 3-16, 4-269 
used in other chapters, 4-329 
CTRL_OUT3 response file, 4-271 
Cursor, 8-2 

Cursor timing output, 4-203 
Cycles 

bus, 2-1, 4-7, 4-331 
coprocessor, 4-8 
refresh, 4-9, 4-75, 4-79, 4-81 
Cyclic Redundancy Check (CRC), 2-6 
See also CRC signature 

Data bus, 8-3 

Data Compare Equal (DCE) condition, 2-10 
Data exchange protocol, 4-116 
Data tied to address, 4-38 
DATA_OUT stimulus program, 3-16, 4-17, 4-24 
used in other chapters, 4-263 
DATA_OUT response file, 4-26 
DECODE stimulus program, 4-283, 4-286 
used in other chapters, 4-46, 4-322 
DECODE response file, 4-288 
Delay line, 7-9 
Delay parameter, 4-61 
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Demo/Trainer UUT, 3-2, 4-1,4-10, 4-63, 6-3 
Device, 8-3 
Device name, 3-20 
Diagnostic messages 
bus test, 4-6 
RAM test, 4-62 
ROM test, 4-36 
Diagnostic program, 3-8, 6-1 
Diagnostic strategy, 6-3 
DIP, 8-3 

Direction control signals, 4-248 

Directory, 8-3 

Discrete I/O, 4-117 

DMA controllers, 4-9 

Downloading programs to the UUT, 5-8 

Drivability, 3-4, 8-3 

Drive capability, 2-9 

DTACK, 4-248, 4-331 

Dual UART (DUART), 4-155 

Dynamic coupling, 8-3 

Dynamic RAM, 4-59, 4-75 

adjusting sync timing for, 7-11 
multiplexed address, 4-75 
refresh, 4-9, 4-75, 4-79, 4-81 
Dynamic RAM Timing functional block, 4-75 
example, 4-79 

keystroke functional test, 4-83 
programmed functional test, 4-88 
stimulus programs and response files, 4-89 
summary page, 4-113 
testing and troubleshooting, 4-75 

Edge, 8-3 

Edge-sensitive inputs, 4-116 
Edit key, 7-18 
Editor, 7-17 

Electromechanical devices, 4-117 
Emulative testing, 2-2 

speed of emulation, 5-8 
enabled_line_timeout fault condition, 4-351 
Examples 

Address Decode, 4-276 
Bus Buffer, 4-250 
Clock and Reset, 4-293 
Interrupt Circuit, 4-316 




Index-4 







Examples, (continued) 

Microprocessor Bus, 4-10 
Parallel I/O, 4-118 
Dynamic RAM Timing, 4-79 
RAM, 4-63 
Ready Circuit, 4-334 
ROM, 4-39 
Serial I/O, 4-155 
Video Control, 4-206 
Video Output, 4-180 
Video RAM, 4-233 
EXEC key, 4-381 

Exerciser, See fault condition exerciser 
External clock signal (sync), 2-10, 7-9 
External control lines, 2-10 
External I/O lines, 4-151 
External synchronization, 8-3 

Fault, 8-3 

fault command, 6-8, 6-9 
Fault condition, 6-8, 7-23, 8-3 

enabiedJine_timeout, 4-351 
exerciser, 7-23, 8-4 
forcing-line, 4-350 
handler, 3-8, 5-8, 6-1,6-8, 8-4 
raising, 8-4 

ram_component, 4-66 
rom_address, 4-44 
rom_comp, 4-44 
Fault coverage, 3-11,5-3, 4-244 
Fault isolation, 2-11 
Feedback loop, 8-4 
breaking, 4-380 
Interrupt Circuit, 4-313 
Ready Circuit, 4-331,4-335 
Forcing lines, 4-379, 8-4 
Forcing signal conditions, 4-9 
Forcing-line fault condition, 4-350 
FRCJNT program, 4-160 
Freerun clock, 2-9 
Frequency, 2-7, 2-9, 4-246, 7-7 
Frequency min-max, 4-79, 4-292 
FREQUENCY stimulus program, 4-301,4-310 
used in other chapters, 4-89, 4-176 
FREQUENCY response file, 4-311 
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Functional block, 3-1,3-11,3-16, 4-1 
Functional test, 1-5, 2-13,3-8, 5-8, 8-4 
TESTJ3US, 4-14 
TEST_BUS2, 6-18, 6-17 
TEST_PIA, 4-124 
TEST_PIA2, 6-20, 6-17 
TEST_RAM , 4-66 
TEST_RAM2, 6-24, 6-17 
TEST_ROM, 4-44 
TEST_ROM2, 6-27, 6-17 
TEST_RS232, 4-160 
TEST_RS232B, 6-29, 6-17 
TEST_VIDEO, 4-186 
TEST_VIDE02, 6-31, 6-17 
TST_BUFFER, 4-262 
TST_CLOCK, 4-300 
TSTCONTEN, 4-15 
TST_DECODE, 4-282 
TSTJNTRPT, 4-322 

used in other chapters, 4-160 
TST_READY, 4-348 
TST_REFRSH, 4-88 
TST_VIDCTL, 4-216 
TST_VIDRAM, 4-238 




getoffset command, 4-77, 7-9 
GFI, See Guided Fault Isolation 
GFI hints, 2-13 
GFI key, 7-2 
GFI procedures, 1-5 
GFI summary, 8-4 
GFI troubleshooting, 2-12, 7-2 
gfi control command, 3-19 
gfi device command, 3-19 
gfi hint command, 3-8, 6-1, 6-9 
gfi test command, 3-8,3-24 
Glitches, 7-8 

Go/no-go test, 4-2, 5-1,5-3, 6-1, 6-3, 8-4 
G0_N0G02 diagnostic program, 6-11 
Ground, 4-4 

Guided Fault Isolation (GFI), 1-5, 2-12,3-12,8-4 


Handler, See fault condition handler 
Hexadecimal, 8-5 
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HOLD line, 4-10 
HOLDA line, 4-10 

In-circuit component tests, 4-381 
In-circuit emulation, 2-2 
Initialization, 3-10,3-17, 4-116 
Parallel I/O, 4-126 
RAM, 4-67 
Serial I/O, 4-162 
Video RAM, 4-238 
Interface pod, See pod 
Internal address bus, 4-246 
Internal operating modes, 4-116 
Internal sync, 2-10 

Interrupt acknowledge cycle, 3-16, 4-315 
Interrupt Circuit functional block, 4-313 
example, 4-316 

keystroke functional test, 4-316 
programmed functional test, 4-322 
stimulus programs and response files, 4-322 
summary page, 4-329 
testing and troubleshooting, 4-313 
INTERRUPT stimulus program, 4-322, 4-326 
INTERRUPT response file, 4-328 
Interrupt response file, 4-328 
Interrupts, 4-8 
Interrupt vector, 4-313 
I/O, 8-5 

I/O module, 2-4, 2-10, 3-17, 7-1, 7-11,8-5 
adjusting sync, 7-9 
breakpoints, 5-7 
calibration, 7-8 
I/O module adapter, 2-10 
I/O module name, 3-20 

Kernel, 4-5 

KEY_1 stimulus program, 4-126, 4-130 

KEY_1 response file, 4-132 

KEY 2 stimulus program, 4-126, 4-133 

KEY_2 response file, 4-135 

KEY_3 stimulus program, 4-126, 4-136 

KEY_3 response file, 4-138 

KEY_4 stimulus program, 4-126, 4-139 

KEY_4 response file, 4-141 

Keys, 4-117 
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Keystroke functional test 

Address Decode, 4-277 
Bus Buffer, 4-251 
Clock and Reset, 4-294 
Interrupt Circuit, 4-316 
Microprocessor Bus, 4-10 
Parallel I/O, 4-118 
Dynamic RAM Timing, 4-83 
RAM, 4-63 
Ready Circuit, 4-335 
ROM, 4-39 
Serial I/O, 4-156 
Video Control, 4-208 
Video Output, 4-181 
Video RAM, 4-233 
Keystroke mode, 1-5 
Known-good UUT, 3-10, 3-12, 7-4 

LEARN function, 7-4, 7-7 
Level 1 programming, 1-3 
Level 2 programming, 1-3 
Level 3 programming, 1-5 
Level 4 programming, 1-5 
Level history, 2-7, 2-9, 7-8, 8-5 
LEVELS stimulus program, 4-217, 4-226 
used in other chapters, 4-238 
LEVELS response file, 4-227 
Library, 8-5 
Line numbers, 3-20 
Local address bus, 4-246 
LOOP key, 7-23 
Loopback, 4-151 

Machine code, 5-8 
Mapped address bus, 4-246 
Marginal signals, 4-292 
Marginal signature, 7-5 
Mask, 8-5 
Masters, 4-5, 7-13 
Measurement device, 3-17 
calibration, 7-8 

Memory arbitration circuit, 4-205 
Microprocessor Bus functional block, 4-3 
example, 4-10 

keystroke functional test, 4-10 
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Microprocessor Bus functional block, (continued) 
programmed functional test, 4-14 
stimulus programs and response files, 4-17 
summary page, 4-31 
testing and troubleshooting, 4-5 
Microprocessor kernel, 4-5 
Milliohmmeter, 7-25 
Min-max, 4-79, 4-292 
Monitor, 8-5 
Msgs key, 7-18 
Multiple failures, 6-10 
Multiplexed address, 4-75 

Net list, 7-11 

Node, 8-5 

Node activity, 5-3 

Node characterization, 2-6 

Node list, 2-12, 7-11,8-5 

Noise, 4-292 

Normal mode, 2-9 

Open circuit, 7-24 
Operator, 8-5 
Operator's display, 8-6 
Operator's interface, 8-6 
Operator's keypad, 8-6 
Output loaded, 7-24 

Overdrive, 2-9, 2-10, 4-4, 4-206, 4-331, 4-381,8-6 
Overlapped ramping operations, 4-244 

Parallel I/O functional block, 4-115 
example, 4-118 

keystroke functional test, 4-118 
programmed functional test, 4-124 
stimulus programs and response files, 4-126 
summary page, 4-149 
testing and troubleshooting, 4-115 
Part description, 7-12, 8-6 
Part library, 2-12, 7-11, 7-12, 8-6 
Partitioning the UUT, 3-1 
Pattern sensitive fault, 4-61 
Patterns, 2-1,3-19 
Peripheral devices, 4-313 
PIA_DATA stimulus program, 4-142 
PIA_DATA response file, 4-144 
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PIAJNIT initialization program, 4-126,4-148 
PIA_LEDS stimulus program, 4-126, 4-145 
PIA_LEDS response file, 4-146 
Pin coverage matrix, 7-21 
Pin numbers, 3-20 
Pin number parameters, 3-21 
Pod Address Sync, 2-9, 3-16, 4-77 
Pod Data Sync, 2-9, 3-16, 4-77 
Pod, 2-4, 2-9, 4-3, 5-8 
library, 8-6 

pod breakpoints, 4-8, 5-7 
synchronization, 8-6 
podsetup command, 4-5 
Power supply, 4-3 
Priority pin, 8-6 

Probe, 2-9, 3-17, 4-292, 7-1, 7-11,8-6 
adjusting sync, 7-9 
calibration, 7-8 
injecting faults with, 5-3 
Program library, 8-6 

Programmable Interface Adapter (PIA), 4-115 
Programmable Interval Timer (PIT), 4-115 
Programmed functional test 
Address Decode, 4-282 
Bus Buffer, 4-262 
Clock and Reset, 4-300 
Interrupt Circuit, 4-322 
Microprocessor Bus, 4-14 
Parallel I/O, 4-124 
Dynamic RAM Timing, 4-88 
RAM, 4-66 
Ready Circuit, 4-348 
ROM, 4-44 
Serial I/O, 4-160 
Video Control, 4-216 
Video Output, 4-186 
Video RAM, 4-238 
Programmer's interface, 1-5,8-7 
Programmer's keyboard, 8-7 
Pull-up resistors, 4-4 

Quality characterization, 2-6 

Raise, See fault condition, raising 
RAM FAST test, 4-59 
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RAM FULL test, 4-59 
RAM QUICK test, 4-59 
RAM TEST key, 4-63 
RAM 

dynamic, 4-75 

sync timing, 7-11 
testing, 4-59 

ram_component fault condition, 4-66 
RAM_DATA stimulus program, 4-67, 4-70 
used in other chapters, 4-126 
RAM_DATA response file, 4-72 
RAM_FILL initialization program, 4-67,4-73 
RAM functional block, 4-59 
example, 4-63 

keystroke functional test, 4-63 
programmed functional test, 4-66 
stimulus programs and response files, 4-67 
summary page, 4-74 
testing and troubleshooting, 4-59 
Ramp function, 4-244 
rampaddr command, 4-246 
rampdata command, 4-247 
RAMSELECT1 stimulus program, 4-89, 4-98 
RAMSELECT1 response file, 4-100 
RAMSELECT2 stimulus program, 4-89, 4-101 
RAMSELECT2 response file, 4-103 
RAM Timing, See Dynamic RAM Timing 
RAS, See Row Address Strobe 
RAS_STIM stimulus program, 4-88, 4-95 
RAS_STIM response file, 4-97 
RD_CSCD program, 4-160 
Read/Write strobe, 4-33 
readout command, 3-21 
Ready button, 3-17 
Ready Circuit functional block, 4-331 
example, 4-334 

keystroke functional test, 4-335 
programmed functional test, 4-348 
stimulus programs and response files, 4-349 
summary page, 4-378 
testing and troubleshooting, 4-331 
Ready signal, 4-248 

READY_1 stimulus program, 4-349, 4-354 
READY_1 response file, 4-357 
READY_2 stimulus program, 4-349, 4-358 


READYJ2 response file, 4-361 
READY_3 stimulus program, 4-349, 4-362 
READY_3 response file, 4-365 
READY_4 stimulus program, 4-349, 4-366 
READY_4 response file, 4-369 
READY_5 stimulus program, 4-349, 4-370 
READY_5 response file, 4-373 
READY_6 stimulus program, 4-349, 4-374 
READY 6 response file, 4-377 
Reference designator, 3-20, 7-11,8-7 
Reference designator list, 7-11 
Refresh, 4-9, 4-75, 4-79, 4-81,4-75, 4-79, 4-81 
Refresh cycle, 4-9, 4-75, 4-79, 4-81 
REFSH_ADDR stimulus program, 4-89, 4-104 
REFSH_ADDR response file, 4-106 
REFSH_TIME stimulus program, 4-89, 4-107 
REFSH_TIME response file, 4-109 
REFSH U56 stimulus program, 4-89, 4-110 
REFSH_U56 response file, 4-112 
Related input pin, 8-7 
Repair, 7-24 

Reset functional block, See Clock and Reset 
RESETJHIGH stimulus program, 4-301,4-304 
RESET_HIGH response file, 4-306 
RESET_LOW stimulus program, 4-301, 4-307 
used in other chapters, 4-217, 4-283 
RESET_LOW response file, 4-309 
Response file, 3-12, 4-17, 7-4, 8-7 
rom_address fault condition, 4-44 
rom_comp fault condition, 4-44 
ROM TEST key, 4-39 

ROM0_DATA stimulus program, 4-46, 4-50 
ROM0_DATA response file, 4-52 
ROM1_DATA stimulus program, 3-16, 4-46, 4-53 
used in other chapters, 4-263 
ROM1_DATA response file, 4-55 
ROM functional block, 4-33 
example, 4-39 

keystroke functional test, 4-39 
programmed functional test, 4-44 
stimulus programs and response files, 4-46 
summary page, 4-57 
testing and troubleshooting, 4-33 
Row Address Strobe (RAS), 4-75, 4-78 
RS-232 port, 4-154 
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RS232DATA stimulus program, 4-163, 4-166 

RS232_DATA response file, 4-168 

RS232JNIT initialization program, 4-163, 4-175 

RS232_LVL stimulus program, 4-163, 4-169 

RS232_LVL response file, 4-171 

Rules for stimulus programs and response files, 4-17 

runuut command, 5-7 

RUN UUT mode, 2-9 

RUNUUT test, 8-7 

Serial interface adaptor, 4-151 
Serial I/O functional block, 4-151 
example, 4-155 

keystroke functional test, 4-156 
programmed functional test, 4-160 
stimulus programs and response files, 4-163 
summary page, 4-176 
testing and troubleshooting, 4-151 
setoff set command, 4-77, 7-9 
SETUP POD command, 4-5 
SIA , See serial interface adaptor 
Side (of I/O module), 2-10, 3-17 
Signature, See CRC signature 
SIP, 8-7 
Softkey, 8-7 
Start signal, 4-180 
State machine, 4-205, 4-331,8-7 
Static electricity, 4-117 
Static logic levels, 4-4 
Static RAM, 4-59, 4-61, 4-75 
Status lines, 4-9 

Stimulus and measurement capabilities, 2-7 
Stimulus function, 7-23 
Stimulus program, 3-6, 3-16, 4-17, 7-2, 8-8 
Stimulus programs and response files 
Address Decode, 4-283 
Bus Buffer, 4-263 
Clock and Reset, 4-301 
Interrupt Circuit, 4-322 
Microprocessor Bus, 4-17 
Parallel I/O, 4-126 
Dynamic RAM Timing, 4-89 
RAM, 4-67 
Ready Circuit, 4-349 
ROM, 4-46 
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Stimulus programs and response files, (continued) 
Serial I/O, 4-163 
Video Control, 4-216 
Video Output, 4-187 
Video RAM, 4-238 
Stop signal, 4-180 
storepatt command, 3-19,4-383 
String, 8-8 
Stuck bus lines, 4-5 
Stuck cells, 4-59 
SUMMARY softkey, 7-17 
Summary of GFI coverage, 7-17 
Summary page 

Address Decode, 4-289 
Bus Buffer, 4-272 
Clock and Reset, 4-312 
Interrupt Circuit, 4-329 
Microprocessor Bus, 4-31 
Parallel I/O, 4-149 
Dynamic RAM Timing, 4-113 
RAM, 4-74 
Ready Circuit, 4-378 
ROM, 4-57 
Serial I/O, 4-176 
Video Control, 4-229 
Video Output, 4-202 
Video RAM, 4-242 
Switches, 4-117 
SYNC key, 4-8 
sync command, 4-8 
Sync timing, 7-9 

Synchronization mode, 2-9, 4-8, 7-8 
with ROM, 4-39 
Synchronous, 8-8 

Synchronous level history, 2-7, 2-9, 2-10, 4-246 
System address bus, 4-246 
System clock, 4-249 

Termination status, 8-8 

Test access, 4-3 

Test access socket, 4-10 

Test access switch, 4-10 

Test function, 7-23 

TEST_BUS functional test, 4-14 

TEST_BUS2 functional test, 6-17, 6-18 
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TEST_PIA functional test, 4-124 
TEST_PIA2 functional test, 6-17, 6-20 
TEST_RAM functional test, 4-66 
TEST_RAM2 functional test, 6-17, 6-24 
TEST_ROM functional test, 4-44 
TEST_ROM2 functional test, 6-17, 6-27 
TESTJRS232 functional test, 4-160 
TEST_RS232B functional test, 6-17, 6-29 
TEST_VIDEO functional test, 4-186 
TEST_VIDE02 functional test, 6-17, 6-32 
Testing and troubleshooting, 2-1, 3-1 
Address Decode, 4-273 
Bus Buffer, 4-243 
Clock and Reset, 4-291 
Interrupt Circuit, 4-313 
Microprocessor Bus, 4-5 
Parallel I/O, 4-115 
Dynamic RAM Timing, 4-75 
RAM, 4-59 
Ready Circuit, 4-331 
ROM, 4-33 
Serial I/O, 4-151 
Video Control, 4-205 
Video Output, 4-177 
Video RAM, 4-231 
Timeout, 8-8 

TL/1 programming language, 1-2,1-6 
Toggle, 8-8 

togglecontrol command, 4-248 
Transition count, 2-7, 2-9, 2-107, 4-246, 7-4, 8-8 
Transition fault, 4-61 
Troubleshooting, 2-1, 3-1,6-1, 7-1, 8-8 
TST_BUFFER functional test, 4-262 
TST_CLOCK functional test, 4-300 
TST_CONTEN functional test, 4-15 
TST_DECODE functional test, 4-282 
TSTJNTRPT functional test, 4-322 
used in other chapters, 4-160 
TST_READY functional test, 4-348 
TST_REFRSH functional test, 4-88 
TST_VIDCTL functional test, 4-216 
TSTVIDRAM functional test, 4-238 
TTL_LVL stimulus program, 4-163, 4-172 
used in other chapters, 4-322 
TTL_LVL response file, 4-174 


UART, See Universal Asynchronous Receiver-Transmitter 

Unguided Fault Isolation (UFI), 7-1 

Unit Under Test (UUT), 1-1,3-1,4-3,8-8 

Universal Asynchronous Receiver-Transmitter, 4-151 

Unprogrammed ROM, 4-38 

Unstable signature, 7-5 

Unused inputs, 4-4 

Use of pod, 2-9 

Userdisk, 8-8 

UUT, See Unit Under Test 

UUT clock, 4-4 

UUT directory, See summary page 
UUT go/no-go test, 3-8, 4-2, 5-1,5-3, 6-1,6-3, 6-9 
UUT partitioning, 3-1 
UUT voltage, 4-5 

Variable signature, 7-5 
Vertical scan rate, 4-203 
Vertical sync, 4-180 
Video cards, 4-180 
Video control, 4-203 
Video Control functional block, 4-203 
example, 4-206 

keystroke functional test, 4-208 
programmed functional test, 4-216 
stimulus programs and response files, 4-216 
summary page, 4-229 
testing and troubleshooting, 4-205 
Video display controller, 4-177 
VIDEO_DATA stimulus program, 4-216, 4-220 
VIDEO_DATA response file, 4-222 
VIDEO_FIL1 initialization program, 4-187,4-200 
used in other chapters, 4-216, 4-238 
VIDEO_FIL2 initialization program, 4-187, 4-201 
VIDEO_FREQ stimulus program, 4-187, 4-190 
used in other chapters, 4-216 
VIDEO_FREQ response file, 4-190 
VIDEOJNIT initialization program, 4-187,4-199 
used in other chapters, 4-217, 4-239 
Video Output functional block, 4-177 
example, 4-180 

keystroke functional test, 4-181 
programmed functional test, 4-186 
stimulus programs and response files, 4-187 
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Video Output functional block, (continued) 
summary page, 4-202 
testing and troubleshooting, 4-177 
VIDEO_OUT stimulus program, 4-187, 4-192 
VIDEO_OUT response file, 4-193 
Video RAM functional block, 4-231 
example, 4-233 

keystroke functional test, 4-233 
programmed functional test, 4-238 
stimulus programs and response files, 4-238 
summary page, 4-242 
testing and troubleshooting, 4-231 
VIDEO_RDY stimulus program, 4-217, 4-223 
used in other chapters, 4-238 
VIDEO_RDY response file, 4-224 
VIDEO_SCAN stimulus program, 4-187, 4-195 
used in other chapters, 4-216, 4-238 
VIDEO_SCAN response file, 4-196 
Visual or acoustic characteristics, 4-380 

Wait state, 4-331,8-9 
Watchdog timer, 4-8, 4-379, 8-9 
Wildcard, 8-9 
Window, 8-9 
Wire list, 7-11 

WRITE BLOCK command, 5-8 
WRITE command, 5-8 
Write control signals, 4-248 
writepatt command, 3-20, 3-21,4-381 



